5 ms·

I predict that Paul will end up abandoning Arc and restarting his quest for the perfect programming language anew. It seems to happen with other successful lang

by lacker 18y ago

I predict that Paul will end up abandoning Arc and restarting his quest for the perfect programming language anew. It seems to happen with other successful languages - Python wasn't Guido's first attempt at a programming language, and Ruby wasn't Matz's first attempt at a language. It's hard to change fundamentals once you have already publicized a language and you have working code, and I think some of the fundamentals of Arc will definitely need to be changed. In particular, the distinctions between the different types of iterable objects - strings, arrays, lists - the inability to design your own objects that are also usable in the same ways as the built-in objects, these are pretty key aspects of the more recent programming languages. I could easily be wrong, but I still suspect the 100-year language quest needs a reboot. Good luck, and I'll keep trying Arc 3 or whatever future stuff there is. I would love a successful language with real macro capability.

pg 18y ago
There wouldn't be any need to make a new language. I can change anything I want in this one. There's very little working code out there; that is in fact probably the main complaint about Arc; and one reason that's so is that I don't want it to be hard to change: http://www.paulgraham.com/core.html http://www.paulgraham.com/core.html I'm not deeply committed to the current approach to iteration. But I don't want to switch to something more complicated till I can prove it's a net win. My standard of proof is whether the proposed language change will make the source of a real program shorter. So if you have an idea for a new iteration abstraction that would make some piece of code in news.arc shorter, please show me the source before and after. (You don't have to implement the new abstraction; just show me what code using it would look like.)
- damienkatz 18y ago
  > My standard of proof is whether the proposed language change will make the source of a real program shorter Short != Clear. Brevity is a false economy, I think you are pushing for the wrong goal.
  - pg 18y ago
    I didn't say that making programs shorter was a sufficient condition for implementing a proposed change.
- lacker 18y ago
  I think the non-object-oriented philosophy in Arc is so deeply ingrained it'll be hard to change without starting over. But really the question is whether any object-oriented philosophy is necessary. My take is, let's say you write a function in Arc that operates on lists. It's recursive using car and cdr. Now ideally, you could also run that function on anything else that is list-like. But in Arc, car only works on lists. Maybe you can fix this without making everything an object, that'd be fine by me. In practice modern programming languages are tending towards a default dynamic-array-like datastructure that supports both random access and amortized-O(1) append. This is so convenient for hacking programs together, I can't believe the 100-year language won't have this as a very basic part of the system. But Arc doesn't do this. In news.arc you have a very Lisp-list-centric way of programming. But I think for many problems less restrictive datatypes are the most convenient. Hash tables and dynamic arrays need to be just as easy as Lisp lists. This is the Python way, the Ruby way, and I think the way of the 100-year language. But I don't know how to make iteration on any of these look equivalent without making the core of the language be more object oriented.
  - jwilliams 18y ago
    To be honest, I don't understand your point fully. Are you able to expand on your points a bit more? Are you saying you believe you need some OO elements of polymorphism on car and cdr? Not sure you need these - there are loop constructs that let for "for each do X". With macros you could make this do almost any type of iteration. I might be missing your point though, as I'm not sure how Objects help in this scenario. Why can't you iterate on hash tables in Arc? ...or another related question, what do you mean by iterate in the context of a hash table? Similarly... Isn't a dynamic array just a list? Or it is specifically the performance of this that you're concerned about - surely this is just an optimisation step rather than a hole in the language?... Either way, I'll agree that they're convenient for hacking programs together :)
    - lacker 18y ago
      Your point is that it is possible to iterate over any sort of data structure. This is true. The problem is that you have to use different sorts of iteration for different data structures. Yes, it is possible to use macros to write code that works over both lists and other iterable things. But that isn't the most natural usage; Arc encourages you to write recursive functions using car and cdr. And if you have a lot of code using car and cdr, you have to rewrite that if you want to convert data from lists to another data type. Objects could possibly give you a polymorphic car and cdr, similar to Clojure, so you just don't have to worry about "what sort of iterable object" a function is going to work on. As far as dynamic arrays versus lists, you can consider it "just an optimization step" as long as you can swap in a dynamic array for a list later on without changing your code. But that isn't possible in Arc because you will have to replace car/cdr with other iteration constructs. I think it's a little unfair to consider the difference between Lisp lists and dynamic arrays just a matter of optimization - there are plenty of things that you can't even play around with when random access is O(n). E.g. randomly shuffling the lines of a large text file.
- charcoal 18y ago
  > There wouldn't be any need to make a new language. I can change anything I want in this one. > I'm not deeply committed to the current approach to iteration. But I don't want to switch to something more complicated till I can prove it's a net win. Paul, this doesn't sound right. Prove that a given change is a net win? Since you obviously can change anything you want at any time, why not go ahead and add the features that seem like they might be worth trying out? See what your users do with them. If the changes/additions turn out to be duds, just rip them out in the next version and let a subset of users whine about it. After all, users will whine either way -- may as well take the path that benefits Arc the most, right?
- DaniFong 18y ago
  One thing that seems to be a net win in scientific programming as well as graphics programming is a method to view code that renders sub and subscripts and unicode characters (as in Fortress). This doesn't reduce the number of nodes required, but it does improve readability substantially. Since reading code is often harder than writing it, and since scientific and graphics code is ordinarily extremely hard to read, and improvement to readability helps. Adding very powerful and general capabilities to syntax, as Fortress does, also reduces the number of nodes required, but I've yet to determine whether the added complexity is worth it.

by lacker 18y ago

pg 18y ago

There wouldn't be any need to make a new language. I can change anything I want in this one. There's very little working code out there; that is in fact probably the main complaint about Arc; and one reason that's so is that I don't want it to be hard to change: http://www.paulgraham.com/core.html http://www.paulgraham.com/core.html I'm not deeply committed to the current approach to iteration. But I don't want to switch to something more complicated till I can prove it's a net win. My standard of proof is whether the proposed language change will make the source of a real program shorter. So if you have an idea for a new iteration abstraction that would make some piece of code in news.arc shorter, please show me the source before and after. (You don't have to implement the new abstraction; just show me what code using it would look like.)

damienkatz 18y ago
> My standard of proof is whether the proposed language change will make the source of a real program shorter Short != Clear. Brevity is a false economy, I think you are pushing for the wrong goal.
- pg 18y ago
  I didn't say that making programs shorter was a sufficient condition for implementing a proposed change.
lacker 18y ago
I think the non-object-oriented philosophy in Arc is so deeply ingrained it'll be hard to change without starting over. But really the question is whether any object-oriented philosophy is necessary. My take is, let's say you write a function in Arc that operates on lists. It's recursive using car and cdr. Now ideally, you could also run that function on anything else that is list-like. But in Arc, car only works on lists. Maybe you can fix this without making everything an object, that'd be fine by me. In practice modern programming languages are tending towards a default dynamic-array-like datastructure that supports both random access and amortized-O(1) append. This is so convenient for hacking programs together, I can't believe the 100-year language won't have this as a very basic part of the system. But Arc doesn't do this. In news.arc you have a very Lisp-list-centric way of programming. But I think for many problems less restrictive datatypes are the most convenient. Hash tables and dynamic arrays need to be just as easy as Lisp lists. This is the Python way, the Ruby way, and I think the way of the 100-year language. But I don't know how to make iteration on any of these look equivalent without making the core of the language be more object oriented.
- jwilliams 18y ago
  To be honest, I don't understand your point fully. Are you able to expand on your points a bit more? Are you saying you believe you need some OO elements of polymorphism on car and cdr? Not sure you need these - there are loop constructs that let for "for each do X". With macros you could make this do almost any type of iteration. I might be missing your point though, as I'm not sure how Objects help in this scenario. Why can't you iterate on hash tables in Arc? ...or another related question, what do you mean by iterate in the context of a hash table? Similarly... Isn't a dynamic array just a list? Or it is specifically the performance of this that you're concerned about - surely this is just an optimisation step rather than a hole in the language?... Either way, I'll agree that they're convenient for hacking programs together :)
  - lacker 18y ago
    Your point is that it is possible to iterate over any sort of data structure. This is true. The problem is that you have to use different sorts of iteration for different data structures. Yes, it is possible to use macros to write code that works over both lists and other iterable things. But that isn't the most natural usage; Arc encourages you to write recursive functions using car and cdr. And if you have a lot of code using car and cdr, you have to rewrite that if you want to convert data from lists to another data type. Objects could possibly give you a polymorphic car and cdr, similar to Clojure, so you just don't have to worry about "what sort of iterable object" a function is going to work on. As far as dynamic arrays versus lists, you can consider it "just an optimization step" as long as you can swap in a dynamic array for a list later on without changing your code. But that isn't possible in Arc because you will have to replace car/cdr with other iteration constructs. I think it's a little unfair to consider the difference between Lisp lists and dynamic arrays just a matter of optimization - there are plenty of things that you can't even play around with when random access is O(n). E.g. randomly shuffling the lines of a large text file.
charcoal 18y ago
> There wouldn't be any need to make a new language. I can change anything I want in this one. > I'm not deeply committed to the current approach to iteration. But I don't want to switch to something more complicated till I can prove it's a net win. Paul, this doesn't sound right. Prove that a given change is a net win? Since you obviously can change anything you want at any time, why not go ahead and add the features that seem like they might be worth trying out? See what your users do with them. If the changes/additions turn out to be duds, just rip them out in the next version and let a subset of users whine about it. After all, users will whine either way -- may as well take the path that benefits Arc the most, right?
DaniFong 18y ago
One thing that seems to be a net win in scientific programming as well as graphics programming is a method to view code that renders sub and subscripts and unicode characters (as in Fortress). This doesn't reduce the number of nodes required, but it does improve readability substantially. Since reading code is often harder than writing it, and since scientific and graphics code is ordinarily extremely hard to read, and improvement to readability helps. Adding very powerful and general capabilities to syntax, as Fortress does, also reduces the number of nodes required, but I've yet to determine whether the added complexity is worth it.