4 ms·

That sounds great for a quick & dirty prototype, or for debugging and testing. But it would be an absolute nightmare for building and maintaining large-scale pr

by adwn 7y ago

That sounds great for a quick & dirty prototype, or for debugging and testing. But it would be an absolute nightmare for building and maintaining large-scale projects.

infinite8s 7y ago
You mean like the internet?
- adwn 7y ago
  The Internet as a whole [1] is not designed or maintained – it evolves. [1] As opposed to its components (infrastructure, protocols, individual websites), which are designed and maintained, and which would in general be a nightmare to design and maintain if they followed the principles described by vidarh.
  - vidarh 7y ago
    Their point is that a lot of the underpinnings of the internet are based on not assuming safe delivery, nor assuming the sender will get things right, and generally accepting that if you want to interoperate reliably you will have a very hard time if you assume everything works perfectly. But taking it a point further: A huge amount of large websites are built on languages with this level of dynamic features, and often take advantage of it heavily. Every site that uses Rails for example (or any Ruby framework) will likely heavily rely on runtime introspection of the database to dynamically generate parts of the ORM apis. I'm right now working on a Ruby application where I went a step further and axed a large chunk of semi-manual API writing by writing a few small components that dynamically generates most of the API at runtime from small pieces of metadata and the actual state of the database. A large chunk of the userinterface is similarly dynamically generated from data dynamically generated by the dynamically generated backend API. There is no way we could deliver what we deliver with the kind of size team we're using if we could not rely on introspection and dynamic features like this to generate most things.
vidarh 7y ago
On the contrary. It's fantastic on large-scale projects in part because it keeps them much smaller. I think you're picturing just losing messages, but that is not what happens unless you explicitly design a system to randomly drop messages. The reality is a system where by default you'll typically still get exceptions if you call something that does not exist (and in production use, the stack traces from those exceptions likely ends up somewhere like Bugsnag), but where you can selectively override what happens and e.g. redirect messages somewhere else. If someone sends a message that truly can not be handled, we'll still throw exceptions. But that flexibility means you save a massive amount of boilerplate. When I switched from C++ to Ruby, that was a major driver - I'd spent years doing meta-programming using templates, and was dimissive of dynamic typing. Until I tried it and realized that for the pitfalls it has, the amount of ceremony and boilerplate that was cut was astounding. I write all my code in a homegrown editor these days. It uses Drb to split the UI frontend with a server that holds all open buffers. Drb is a Ruby RPC library that uses the ability to intercept all messages to dynamically create proxy objects that serialize calls over the network connection. Because we can do that, it's almost entirely transparent and no custom code whatsoever needs to be written. If the server side throws an exception, by client catches it and throws me into a REPL (or it could have dumped state and exited if I preferred). Messages don't get randomly lost, even though the client side objects have no idea what the actual interfaces of the server side objects are.

by adwn 7y ago

That sounds great for a quick & dirty prototype, or for debugging and testing. But it would be an absolute nightmare for building and maintaining large-scale projects.

infinite8s 7y ago

You mean like the internet?

adwn 7y ago
The Internet as a whole [1] is not designed or maintained – it evolves. [1] As opposed to its components (infrastructure, protocols, individual websites), which are designed and maintained, and which would in general be a nightmare to design and maintain if they followed the principles described by vidarh.
- vidarh 7y ago
  Their point is that a lot of the underpinnings of the internet are based on not assuming safe delivery, nor assuming the sender will get things right, and generally accepting that if you want to interoperate reliably you will have a very hard time if you assume everything works perfectly. But taking it a point further: A huge amount of large websites are built on languages with this level of dynamic features, and often take advantage of it heavily. Every site that uses Rails for example (or any Ruby framework) will likely heavily rely on runtime introspection of the database to dynamically generate parts of the ORM apis. I'm right now working on a Ruby application where I went a step further and axed a large chunk of semi-manual API writing by writing a few small components that dynamically generates most of the API at runtime from small pieces of metadata and the actual state of the database. A large chunk of the userinterface is similarly dynamically generated from data dynamically generated by the dynamically generated backend API. There is no way we could deliver what we deliver with the kind of size team we're using if we could not rely on introspection and dynamic features like this to generate most things.

vidarh 7y ago

On the contrary. It's fantastic on large-scale projects in part because it keeps them much smaller. I think you're picturing just losing messages, but that is not what happens unless you explicitly design a system to randomly drop messages. The reality is a system where by default you'll typically still get exceptions if you call something that does not exist (and in production use, the stack traces from those exceptions likely ends up somewhere like Bugsnag), but where you can selectively override what happens and e.g. redirect messages somewhere else. If someone sends a message that truly can not be handled, we'll still throw exceptions. But that flexibility means you save a massive amount of boilerplate. When I switched from C++ to Ruby, that was a major driver - I'd spent years doing meta-programming using templates, and was dimissive of dynamic typing. Until I tried it and realized that for the pitfalls it has, the amount of ceremony and boilerplate that was cut was astounding. I write all my code in a homegrown editor these days. It uses Drb to split the UI frontend with a server that holds all open buffers. Drb is a Ruby RPC library that uses the ability to intercept all messages to dynamically create proxy objects that serialize calls over the network connection. Because we can do that, it's almost entirely transparent and no custom code whatsoever needs to be written. If the server side throws an exception, by client catches it and throws me into a REPL (or it could have dumped state and exited if I preferred). Messages don't get randomly lost, even though the client side objects have no idea what the actual interfaces of the server side objects are.