gouranga

62 ms·

631.
by gouranga 15y ago
Good stuff! Need more simple practical things like that - it is really interesting. Slight side topic: Bit of "biology" I've been experimenting with at home based on stuff I had lying around. Works really well... Items: 2l coke/water bottle
632.
by gouranga 15y ago
They are optionally nullable. Unfortunately, people seem to think that making use of them everywhere is cool :(
633.
by gouranga 15y ago
There is the compilation of the JVM via CoffeeScript to Javascript. It's hard to illustrate that in text.
634.
by gouranga 15y ago
Corrected - thank you :)
635.
by gouranga 15y ago
Agreed, apart from nullable types which I think is a misfeature (having dealt with the inevitable null reference/null value tristate hell left by some developers).
636.
by gouranga 15y ago
I've written about 400kloc in C# 4.0 and I haven't had a need yet :(
637.
by gouranga 15y ago
Talk about abstraction! Java -> bytecode -> JVM -> CoffeeScript -> JavaScript -> interpreter/JIT -> machine code -> CPU -> hardware. Turtles all the way down...
638.
by gouranga 15y ago
We're paying for the support and insurance against failure, not the features. You don't do manual SQL updates. Why would you if you have an ORM? You update the domain and it does all of that stuff for you. I only care about the domain whic
639.
by gouranga 15y ago
To be honest, if you have a good ORM, it's better at writing SQL than you are. Compare to compilers being better at writing machine code...
640.
by gouranga 15y ago
I agree. I'm not advocating KV stores.
641.
by gouranga 15y ago
Did I say I was anti-RDBMS? Not at all. I'm just careful. I still use RDBMS for everything - just differently and I avoid a fair amount of the tempting features. I'm not an advocate of NoSQL. The ideology came out of necessity and 20 years
642.
by gouranga 15y ago
The ORM layer does give you ACID or rather it doesn't take it away. It does joins and transactions. It's just an abstraction. I suggest you read up on PoEEA [1] as I don't think you understand what an ORM is properly or you've had experienc
643.
by gouranga 15y ago
I agree. For a fresh start (greenfield) it's probably fine. Unfortunately for 90%+ of IT products, it's not a greenfield. That's where the problem comes.
644.
by gouranga 15y ago
There is no replication of features at all (backup/restore is fundamentally different - it exports the domain to disk, not the schema). Well we could shift a deployment to Amazon RDS (Oracle or MySQL) quite happily in a couple of hours with
645.
by gouranga 15y ago
That bit is cheap. How much does the storage subsystem cost? You know the whole stack of fully redundant iSCSI/FC kit behind it?
646.
by gouranga 15y ago
It is robust and amazing. I agree but if you push it to the limits it will bite you on the arse. Probably about the same as you on just SQL Server and half as much again on Oracle...
647.
by gouranga 15y ago
> At peak hours as of 2007 the database handles around 2-2.5k transactions per second, which generate roughly 40,000 input/output operations per second on the disks. That's not much...
648.
by gouranga 15y ago
In fact they tend to optimise per engine. If you look at NHibernate for example, if you do paging on SQL 2005+ it will use CTE yet on MySQL it will use LIMIT clauses underneath. Some enterprise products have a really crappy schema with an O
649.
by gouranga 15y ago
It's even harder to VERIFY correctness inside the DBMS with respect to keeping it managable and debuggable. That's why we pull it out into code behind an ORM. We can run a fully automated test suite in 30 minutes which will verify that the
650.
by gouranga 15y ago
Which is why we don't like them :) Databases are for putting stuff in when you don't immediately need it. The DBA mindset pushes that the DB is the hammer for all nails.
651.
by gouranga 15y ago
No just there is a difference between large and complicated.
652.
by gouranga 15y ago
Cheaper yes but if you know the courier services in the UK at the time, there is no guarantee it'd get there on time.
653.
by gouranga 15y ago
Hibernate and nhibernate.
654.
by gouranga 15y ago
Instagram isn't very complicated to be honest so I doubt that's a good scalability example.
655.
by gouranga 15y ago
I'd like to know the reason that was downvoted...
656.
by gouranga 15y ago
It was incredibly inconvenient you mean? In the mid-90s, before broadband proliferation, I managed to get from London to Manchester via train (200 miles) which takes bloody forever. When I got there, I realised I'd forgotten the damn softw
657.
by gouranga 15y ago
It goes much faster I agree. However you are very short sighted. That black box doesn't go on forever. It will work fine for the first 50 users, seems ok for the next 100, 500 we're doing ok. 1000 BOOM! Then what do you do? I'd rather have
658.
by gouranga 15y ago
Rubbish. When the successful capitalists lobby politicians and pay them off regularly, it's a closed loop between government and corporations. Us peons don't get a look in.
659.
by gouranga 15y ago
Decades of work is pretty wrong to be honest. They approach the wrong end of the problem. They never consider efferent coupling between database objects which is the absolute killer in anything but simple projects regardless of what is prom
660.
by gouranga 15y ago
If you look at most "corporate" IT platforms, they tend to have favourite database engines that they need to use. If you have DBMS portability, then it gets one foot in the door straight away. Also contrary to the norm here, some applicatio

More ›