81–85 of 85 posts
Earlier quoted context omitted.
Alternatively you could compare Ruby to SML and appreciate how far we've regressed.
Comparing, and... nope. They were both developed within a few years of each other, and are from different paradigms, so regression seems like a cheap dig, but not an accurate one.
Earlier quoted context omitted.
Assuming your concern is across a single/uniform language: How about Smalltalk as a basis or the foundation of what you want? If somebody pursues the approach, how hard would it be to develop a layer that takes care of the safe-unsafe issue? MOP: extensibility without ubiquitous useful patterns. My experience says that "ubiquitous patterns" manifest when you use a technology against real problems. So use the MOP to t…
"How about Smalltalk as a basis or the foundation of what you want? If somebody pursues the approach, how hard would it be to develop a layer that takes care of the safe-unsafe issue?" I don't feel like Smalltalk is going anywhere, so I don't know. Smalltalk has some great lessons, but I don't think well defined data access is one of them. Haskell, as mentioned earlier in this thread, has some pretty strong guarantee…
For sure. To me it seems like a good environment for isolating processes and users in security and execution contexts -- just boot up an instance, perform a task and then destroy. How it applies to data processing is not very clear.
"But the specific product is of interest to me, not just the environment that spawned it."
I see what you mean. I feel that anyone creating such a product/environment will run into massive problems that are very non-technical. How do you get language owners/implementers to agree to a common standard especially in today's web where we see common denominators of data sharing like RSS slowly being strangled by the big players -- let alone co-operations in programming environments/runtimes. The reason I mention the "big players" is that without somebody getting funded to think about this in a serious manner for an extended period of time, it will be very hard. Organisations like universities have the brainpower for this but not the money or the drive.
Something encouraging here is the recent slew of JVM languages -- they share objects with Java. Limitation here is its all on a single platform.
Maybe with the recent announcement of a Haskell kernel for IPython environment there is room for doing some inter-lang op work?
Earlier quoted context omitted.
I recently had a need for an algorithm that did some pretty complex geographical data interpolation that was faster than the existing implementations. The modern vendor library I was using took about a minute to compute. I searched through some old archives and found a scanned in PDF of the algorithm I wanted to implement from a late 60s fortran implementation. I converted it to node.js and Presto! The thing takes th…
Fortran is totally known for its computational prowess.
I've wondered if it would take a 'non-programmer' to develop a new metaphor/representation of programming that is more futuristic. The OP has some interesting suggestions of characteristics that 'futuristic programming' would have, including safe object traversal, ubiquitous object extensions, and code transport, but these are still conceived within the paradigm that we think of programming today. Maybe programming n…
There is a catch-22 here in that in order to come up with new ideas, you need to be fairly well-versed in what kinds of things computers can do but can't have been indoctrinated into assuming programming has to work a certain way.
Earlier quoted context omitted.
There is a catch-22 here in that in order to come up with new ideas, you need to be fairly well-versed in what kinds of things computers can do but can't have been indoctrinated into assuming programming has to work a certain way.
That is not a catch-22, that's a filter.