Live data from Hacker News

Ten predictions (2004)

sites.google.com

191–200 of 324 posts

Re: Ten predictions (2004)

#191
post #189

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…

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.

Re: Ten predictions (2004)

#192

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…

To whom did 'functional' mean the same thing as 'lisp'? I'm always astonished when people conflate these two things. Lisp encourages you to put the forms that evaluate to a value in the position you would otherwise put a variable that has been set to that value, sortof code in place. That is kindof like functional programming. However, lisp does not avoid side effects or mutability, in fact virtually all operators in…

You are also not getting the point you complain about completely clear, it is not that "Lisp isn't really that functional", Lisp != Common Lisp and being a Lisp and being functional is to some extent orthogonal those days - Clojure is a very functional Lisp for example, similarly Racket, Common Lisp much less so. The original McCarthy Lisp paper was to a large extent a paper in theory of computation, using Lisp as a vehicle for things like proving program correctness, so that Lisp was purely functional, otherwise you could not do much formal reasoning with it. I guess to be completely clear one has first to define what one means by "Lisp".

Re: Ten predictions (2004)

#193
post #43

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.…

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. I think he means more like wordpress.com, WPEngine and those ilk. Those are currently the most lucrative, but there are other examples of businesses monetising open source by hosting it.

I agree. And I think more and more open source web applications are using SaaS "supported" versions in addition to their open source/privately hosted options. I think this prediction is pretty spot on as well.

Re: Ten predictions (2004)

#194

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…

I got a new job in December. This company mostly uses Ruby and PHP. I was given an assignment for which they scheduled 2 weeks. I wrote the whole thing in Clojure, my new favorite language. I got it done in 1 week (6 days). After I was done, I asked if it was okay if I used Clojure. The folks I work with had no problem with that. They asked were impressed with my speed, part of which I attribute to Clojure. I am the…

[deleted]

Re: Ten predictions (2004)

#195

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…

I got a new job in December. This company mostly uses Ruby and PHP. I was given an assignment for which they scheduled 2 weeks. I wrote the whole thing in Clojure, my new favorite language. I got it done in 1 week (6 days). After I was done, I asked if it was okay if I used Clojure. The folks I work with had no problem with that. They asked were impressed with my speed, part of which I attribute to Clojure. I am the…

So, if I were to do your two week assignment in one day, in C, would that mean that C is much better than Clojure?

What if I gave your Sysadmin a make file that would build a Debian package or RPM package rather than expecting him to maintain some complex and silly deployments system? The sysadmin would be my new best friend, but would that imply that the language I used was better?

You are doing some seriously sloppy thinking here.

Re: Ten predictions (2004)

#196

Earlier quoted context omitted.

> We got NoSQL (esp. JSON based ones) instead of XML. Close enough though. JSON is basically XML with 50% less bullshit. It does less but it does it so much more elegantly than XML - and has the further benefit of a syntax similar to that of structured data in such languages as Javascript (duh), Python and Ruby - that it was a shoo-in to squeeze XML out of most non-enterprise uses, at least on the data transfer forma…

JSON is basically XML with 50% less bullshit. I don't get this. XML has the capacity of being as simple as you want it to be. You don't need schemas, namespaces, xpath, and so on, and can make your XML life every bit as easy as JSON. In many ways easier given that JSON doesn't even have a bloody date or time type. But if you do want strong-type validation, schemas and namespaces are there for you. If you want an easy…

I think the 50% less bulshit figure is pretty generous. Let's not forget that, unless you opt out of it, most XML parsers, when given user-generated input, will do lots of crazy stuff. In the best case scenario, the machine that parsed the input will fall victim to DoS. In the worst, we have good old remote code execution. Tipically, an attacker will be able to read lots of files from the servers and make arbitrary network connections, many times from the viewpoint of a machine inside a corporate firewall. As a spare-time security researcher, let's say I absolutely love XML. As a developer, I despise it.

Re: Ten predictions (2004)

#197

Earlier quoted context omitted.

JSON is basically XML with 50% less bullshit. I don't get this. XML has the capacity of being as simple as you want it to be. You don't need schemas, namespaces, xpath, and so on, and can make your XML life every bit as easy as JSON. In many ways easier given that JSON doesn't even have a bloody date or time type. But if you do want strong-type validation, schemas and namespaces are there for you. If you want an easy…

I think the 50% less bulshit figure is pretty generous. Let's not forget that, unless you opt out of it, most XML parsers, when given user-generated input, will do lots of crazy stuff. In the best case scenario, the machine that parsed the input will fall victim to DoS. In the worst, we have good old remote code execution. Tipically, an attacker will be able to read lots of files from the servers and make arbitrary n…

I'm sorry, but the vague handwaving about security issues with XML is utter nonsense. There have been issues, just as there have been issues with JSON, HTML, or any other parsed or shared content. Alluding to some vast chasm of danger is absurd, made especially obvious that XML remains the lingua franca or most enterprise systems and interchanges (meaning the ones that people are most interested in trying to compromise).

Re: Ten predictions (2004)

#198

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.…

> We got NoSQL (esp. JSON based ones) instead of XML. Thank god we dodged that bullet. I'm just glad people see XML for what it really is (useful, but not that useful). > Not really. We are already in the multicore age, and it will only get moreticore. The problem is multi-threaded has never really took off, even with all the cores we have today. There is still no silverbullet to harnessing parallelism. > Apple's lap…

Did you actually read what he said?

> Of course most programmers will still be average, by definition. The problem is that the average level of quality and productivity probably won't have changed all that much.

It would appear not.

It's always funny how people take a serious person who has otherwise written a very insightful article, take a sentence out of context, and proclaim it silly.

Re: Ten predictions (2004)

#199

Earlier quoted context omitted.

> We got NoSQL (esp. JSON based ones) instead of XML. Close enough though. JSON is basically XML with 50% less bullshit. It does less but it does it so much more elegantly than XML - and has the further benefit of a syntax similar to that of structured data in such languages as Javascript (duh), Python and Ruby - that it was a shoo-in to squeeze XML out of most non-enterprise uses, at least on the data transfer forma…

JSON is basically XML with 50% less bullshit. I don't get this. XML has the capacity of being as simple as you want it to be. You don't need schemas, namespaces, xpath, and so on, and can make your XML life every bit as easy as JSON. In many ways easier given that JSON doesn't even have a bloody date or time type. But if you do want strong-type validation, schemas and namespaces are there for you. If you want an easy…

1. JSON has an easy way to specify data types. In XML you have to have multiple nested tags. In JSON my document can be:

  {"mynumber" : 5, "mylist" : ["one", "two", "three"]}
Simple, neat, and fits on one line.

In XML this has to be

  
  
    5
    
      one
      two
      three
    
  
Of course, I don't know what you're talking about "JSON doesn't even have a bloody date or time type" when XML doesn't have anything but strings. In order to parse this, I'd have to have code which looks for tags and runs my language's atoi() on the content.

Maybe there are libraries that do this automatically. If there are, the XML community does an excellent job of hiding them from developers; I've worked a fair bit with XML, and haven't found them.

2. Easy interface with popular languages. You can just copy-paste a JSON string into a Javascript / Python app. (Warning: If you do this programmatically, it's going to be a security vulnerability.) Whereas if you want to use XML, you have to jump through a lot of hoops. Especially with Java; AFAIK the Java standard lib only ships a specification for XML parsing. So while the org.w3c.xml namespace is there (or whatever it's called, it's been a while), you have to install some Apache lib called Xerces or Xalan or Xavier (or whatever it's called, it's been a while) in order to have XML support.

This is Java's fault, not XML's; but XML was a shiny cool thing at about the same time Java was, so a lot of peoples' main XML experience (or at least mine) is in Java.

3. Is a subset of many popular languages. A lot of people -- especially web developers -- only know one language. If you know JS, then you know JSON. But XML syntax and semantics is very different from most programming languages, and that's a barrier. (General XML is much different than HTML. In particular, you can always see what HTML "does" by loading it in the browser because everything has default styles; not so with a general XML format, unless you go through the pain of writing a complete style yourself.)

Re: Ten predictions (2004)

#200

Earlier quoted context omitted.

> We got NoSQL (esp. JSON based ones) instead of XML. Close enough though. JSON is basically XML with 50% less bullshit. It does less but it does it so much more elegantly than XML - and has the further benefit of a syntax similar to that of structured data in such languages as Javascript (duh), Python and Ruby - that it was a shoo-in to squeeze XML out of most non-enterprise uses, at least on the data transfer forma…

JSON is basically XML with 50% less bullshit. I don't get this. XML has the capacity of being as simple as you want it to be. You don't need schemas, namespaces, xpath, and so on, and can make your XML life every bit as easy as JSON. In many ways easier given that JSON doesn't even have a bloody date or time type. But if you do want strong-type validation, schemas and namespaces are there for you. If you want an easy…

I don't understand the complant that JSON doesn't support a date/time format.

It supports numbers and strings. You can use unix timestamps, you can use ISO 8601, you can use any format that makes sense for your application.

JSON doesn't support a Date/Time object because it's a data format. XML doesn't support a Date/Time object either.

Now if you want to complain that the JSON parsers don't automatically convert ISO 8601 dates into Date/Time objects, I understand.

To me 50% less bullshit means 50% less typing and maybe getting something wrong. JSON is easy to read and write by hand, which happens a lot.

XPath/XQuery and XSLT are nightmares in my opinion. I'd much rather type `Foo.bar` or `_.each(Foo.items, function(item) {...})` and be able to easily debug when something goes wrong.

Post reply on HN