benkant

A lot of this content originates from 4chan and other image boards.

Mathematica not being Open or free is the only complaint I buy. As for it missing features, I'd wager adding them to Mathematica would be less work than building a CAS from scratch with them- in which case I'm sure you'll be missing features from the original.

We were writing web based GIS in 1996, using ESRI's MapObjects IMS. Tiling, projections, yes these were solved problems by then using available commercial software.

We were storing data in Oracle or DB/2 with ESRI's SDE sitting on top, because at that time no mainstream RDBMS had spatial types.

I don't recall if SDE supported SQL Server back then. That aside, you could have built TerraServer with COTS tech in 1997.

TerraServer was impressive due to being publically available. Nothing we built at the time was available to the public as far as I remember. But it existed.

And that's just web based stuff, which really is the easy part. Large scale GIS had been around for decades prior.

Reminds me of Career Move, in Martin Amis' 2000 collection Heavy Water and Other Stories. In it screenwriters struggle for their art while poets are optioning treatments of their poems for "mid six figures".

I don't know whether or not judging programming ability is hard. But judging ability in computer science, which is what we're talking about, is not at all "very hard".

I'm sorry to hear your anecdote. I would have to come see your particular situation to see exactly what you mean by 1, 2, 5, because those don't seem unsolvable, but in general:

> 3) Orthoganality

You've introduced that by treating a relational store as a "hole to put your shit in". It's not fair to blame the database for that.

> 4) Duplication

Not with the project that is the topic of this thread you don't.

> 6) Lock in

As I mentioned in my original comment, you can be locked to your database or you can be locked to your ORM/DAO/ActiveRecord/DB client library or whatever it is you're using.

Not using database features isn't the key to heaven anymore than using them is the key to hell. I just meant to point out that in my experience they are underused massively.

> There's also the "demarcation" issue.

This is probably just as significant as vendor independence or technical issues. But I remember it a little differently.

In the old days you'd have programmers who did the code and the DBAs who were tasked with making sure the data wasn't broken. They would write SPs, use constraints and triggers etc. Depending on the team programmers might do these as well or instead, but it was the DBAs domain ultimately.

Then programmers wrote ORMs and started doing all that stuff in code and somehow managed to seize control of data validation and semantics from the DBAs.

That's what views are for.

I never mentioned performance or scaling as reasons for using a database's features- though they might be worth considering. The fact I never said those words and it fired you up says more about your experience than mine I imagine.

This is good work and if I ever did web development, it would be like this. Why people in the web world don't use stored procedures and constraints is a mystery to me. That this approach is seen as novel is in itself fascinating.

It's like all those web framework inventors didn't read past chapter 2 of their database manuals. So they wrote a whole pile of code that forces you to add semantics in another language elsewhere in your code in a language that makes impedance stark. PostgreSQL is advanced technology. Whatever you might consider doing in your CRUD software, PostgreSQL has a neat solution. You can extend SQL, add new types, use PL/SQL in a bunch of different languages, background workers, triggers, constraints, permissions. Obviously there are limits but you don't reinvent web servers because Apache doesn't transcode video on the fly. Well, you do if you're whoever makes Rubby on Rails.

The argument that you don't want to write any code that locks you to a database is some stunning lack of awareness, as you decide to lock yourself into the tsunami of unpredictability that is web frameworks to ward off the evil of being locked into a 20 year database product built on some pretty sound theoretical foundations.

Web developers really took the whole "let's make more work for ourselves" idea and ran with it all the way to the bank.

You'd have to pay me a million dollars a year to do web development.

Consider the sequence

1, 3, 5, 7

what comes next? 9 right? Or is the sequence generated by 2n − 1 + (n − 1)(n − 2)(n − 3)(n − 4) for n ∈ N. Then we've got 33.

"among all hypotheses consistent with the observations, the simplest is the most likely"

33 is correct, but it's less likely to be the basis for the generation of the sequence.

Your answer of (x, 2x, 4x) proves the puzzle illustrates the confirmation bias, at least in your case.

Does the unit test that confirms your function returns the expected result given one set of arguments prove it correct?

I'm definitely not saying the internet is centralised! Perish the thought. I never mentioned it- the discussion was to do with the web specifically.

Forget the web as a whole and consider a single service such as HN. That graph has |clients| >> |servers|. More than the cardinality the client and server nodes are different in kind.

I consider a decentralised architecture to be one where the nodes can in principle participate equally.

You are arguing that the web is decentralised because there are many services to choose from. I don't disagree, but that's above the application layer protocol- which is what I thought we were discussing. In that case decentralisation happens above the application layer. So in humans? By that definition BBS's were decentralised because I could call a different one.

In other words, yes the web is decentralised because I can choose from many Forex APIs. But at the logical application layer of HTTP, OANDA is a centralised service. HTTP addresses point to specific nodes which may or may not be individual servers at the network layer, but from the point of view of HTTP that's what you address. In a decentralised application layer protocol I would expect to that not to be the case.

That Google is proposing this service is proof that individual web services are centralised. There's a single point of failure.

We're talking at different layers. It's just semantics from here on in.

We're talking about the web as an application layer protocol. By your definition everything that happens on the internet is decentralised. That's not untrue if you look at it from the point of view of TCP/IP, but that's tangential to the conversation we're having.

You seem to be conflating the web with the internet.