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.
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.
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.
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.
Yep, the web is a distributed system. Yep, the web offers many services, and many providers offer the same class of service.
However, each and every one of those services are centralised in a technical sense on account of HTTP. Why might an alternative be useful? Consider the solution the Google service we're addressing is putting forward cf. Content Addressable Networking systems[0]. I can't spend any more time explaining, sorry. This might help- note the levels of centralisation in each generation of P2P systems:
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.
That's another way to look at it, but you're using decentralised to indicate there are many large nodes- I would say that's simply distributed. I'm using centralised to indicate that communications are via those large nodes, which mostly don't communicate with each other.
It's client/server on a massive scale. Just because the servers are public, doesn't make it decentralised.
Google makes money precisely because the web is centralised. If we moved to P2P systems they could still provide an index, but I'd wager far less data would ultimately pass through them. Not to mention that if people were more in control of their data rather than LinkedIn, Facebook, Flickr, YouTube, I bet they'd be less inclined to having it indexed publically simply because they have a choice.
There's all sorts of network effects and shitty incentives at play, and it's a shame.
My twitter rant (not the whole thing even)
> though they have their place, centralised systems reinforce the role of the middle man, which is prime for rent-seeking and lopsided value
> in reality networks exist on a continuum between centralised/decentralised. The web makes it difficult to choose the correct degree per case
> both centralised and decentralised systems have trust issues, but they are different in kind not magnitude
> the incentives are wrong for innovation. Google requires centralised, so HTTP is fine. Ubiquity, so HTML is fine
> web developers have spent years becoming skilled in their corner and are incentivised to defend and perpetuate the platform
> if you think discoverability, zero-install and sandboxes are only possible on the web, I invite you to consult the literature
> we could have decentralised, secure, simple, efficient primitives, but network effects and incentives steer us away
> tech solutions are moot unless they incentivise behaviour that leads to better returns for everyone. layers on HTML/HTTP will never do that
I'm aware of the difference between residency and citizenship, that's not the issue. I deny what they are offering is typically something requiring residency. Anecdotally- I don't have residency (or citizenship to be clear) in Singapore but have government ID there I use for their services.
If they plan to expand the program to allow things typically afforded to residents of a country then that would be something. I doubt it however.
Calling this e-Residency is a mistake. It's confusing enough that a commenter here was unsure if they were eligible because their country does not allow dual citizenship.
It's a government identity you can apply for and use online that allows you to register companies, among other things- right?
As an electronic resident of Estonia what are you entitled to that you can't do in Singapore, Hong Kong, the UK, etc? The only difference I can see is that in those places you likely need to visit the country to setup the company. Those countries certainly wouldn't call that process airplane-Residency.
Electronic mail is mail that you send electronically. Here, e-Residency is not residency in any definition of the word, even the ephemeral kind. An e-Residency does not afford the bearer any entitlements not offered to a non-bearer, save for not requiring a flight to Estonia.
That said, I appreciate the innovation in an online government ID card for foreigners. The name is a mistake. More accurate would be to call it e-Airplane.
As I haven't read everything about this, I'm willing to admit there's a chance I'm wrong.
edit: An issue was opened[0] but there has been no response. I find it hard to believe a C&D comes with a gag order but IANAL.
I find it frustrating there's no transparency on this, and I hope I'm not being overly dramatic, but I would have expected more openness here.
There could be a very reasonable explanation for keeping mum on this, I guess.
[0] https://github.com/openai/universe/issues/126