3 ms·

Alright, looks like I may be downvoted to oblivion. I still believe I'm on to something. Would any downvoters care to take a minute to share what you think I'm

Alright, looks like I may be downvoted to oblivion. I still believe I'm on to something. Would any downvoters care to take a minute to share what you think I'm missing? Seems like the polite thing to do. I know you're busy, so make it short and sweet if you have to, but if I'm wrong/naive/ignorant, please, help me out.

deleted 13y ago
[deleted]
Helianthus 13y ago
There is a reason there are so many languages extant. They each serve a purpose. What exactly do you think you're on to? Insight has built all of the things that you're hoping to replace. So what are you bringing to the table?
- charlieflowers 13y ago
  > Insight has built all of the things that you're hoping to replace. Who/what is "insight"? I didn't follow this sentence. > So what are you bringing to the table? If this has been done or thought out before, possibly nothing. But I'd be OK with that, because I'd be excited to see the results. If you have a link or a search term, please pass it on.
chipsy 13y ago
Here's my question. What does "ground up" buy you? It is ideologically good, for sure. But it requires a viewpoint about future programming that is similar to existing programming: we'll write systems that are hard to maintain and are burdened with a lot of code doing relatively low-level data manipulations whose implementation can be automated. But if our future programming environments are "smaller and sleeker" in all respects(as is anticipated by, for example, the VPRI work on STEPS) this would be the wrong optimization to make. The cost of maintenance will go down across the board because the new languages let us express the change with less effort, and then complicated refactoring becomes less necessary again. (Counterpoint: We just build even more complex systems and then need better refactoring tools. An endless cycle...)
- charlieflowers 13y ago
  I love a lot of the principles behind VPRI and STEPS. But it strikes me as a very futuristic ideal, not something we're close to being able to use concretely and productively today. And I get the irony! The exact same thing is true of my post. But I think I'm not trying to shoot as high as you are. If we can find a way to make the VPRI/STEPS vision a reality, I'm all for it. I think what I'm proposing is a less ambitious interim step.
danieldk 13y ago
I still believe I'm on to something. I didn't vote at all, but you state: In other words, the original language has to capture more of the programmers intent (probably by inferring most of it). But I think that your comment fails to provide (1) an argument why homoiconic languages such as Lisp and Prolog do not fit the bill, since they are easy to rewrite (code is data); and (2) how this hypothetical language differs over languages that are easy to parse and have simple semantics, such as Java and C#, if most of the intent needs to be inferred. I'd rather like to see better libraries for e.g. Java (Groovy provides the REPL :)) to do this, than yet another language.
- charlieflowers 13y ago
  (1) Homoiconic languages are actually a smaller scale instance of exactly what I'm talking about. They were designed from the ground up to allow for compile-time code rewriting, and because that was the primary driving goal from the start, they have amazing code rewriting capabilities that other languages cannot begin to dream of. But the distinction I was trying to draw is that I'm talking about going further with that idea. Homoiconic syntax only allows for local code re-writing, but there are many other kinds of things we'd like to programmatically transform on a large codebase. Half-baked examples: We'd like to replace all use of new/delete with smart pointers, but only in source files that are in one particular section of the codebase. Or we'd like to move all our unit tests from being in a separate package/dll, to being included in the same dll but surrounded by compiler pragmas. (2) How the language would differ -- I don't yet know. But just as homoiconicity says "let's allow our end goal of automatic code rewriting to dictate our syntax", what I'm trying to say is, "let's allow our end goal of automatic refactorability / transformability to dictate all the programming language design decisions we make." I think probably many of the things Raphael_Amiard mentions in this thread would be a part of it: strong inferred typing, perhaps, and a strong package system. Perhaps the ability to write some kind that was intentionally agnostic about how it would be packaged, and write some code elsewhere that says "take that code over there, and package it thusly." It would need to know if certain snippets were functionally pure (sort of how D does with "pure nothrow"), because then it would know it have more freedom with how it could transform that code. Hopefully that clarifies the idea. It's hand wavy and high level, but it's a new (to me) idea that's only at the hand wavy stage so far.
haberman 13y ago
If you are serious and passionate about this idea, I recommend digging in deeper and thinking of more specific examples of how you can improve on the status quo. You say that you want to design from the ground up to be more transformable than anything else, but without specifics this is just a goal, and it's not clear that a new language is necessary or would buy you anything. For example, take your idea about wanting to be able to replace all instantiations with a function call instead. There's no need to invent a new language for this; the AST of a program in most any language would have enough information to write this refactoring capability into a tool. The hard part would be expressing the refactoring itself; how do you specify exactly the pattern you are trying to match, and exactly what you want to rewrite it to, in a way that is easy to use? Maybe some other ideas you have would require a new language, but it's hard to say unless you are more specific about what you want. You might find that a lot of your ideas are implementable on top of existing systems. Designing "from the ground up" has a certain appeal to it, but to justify the extreme amount of effort a new language would take, I think you'd want to be more specific about what the clean break would buy you.
- charlieflowers 13y ago
  Thanks for the comment. I agree that the AST of a program provides the raw material that could empower these kinds of transformations. But certain language features make it hard (like the C preprocessor, to cherry pick an example). And I guess I'm exploring the question: What would a language look like whose goal was to make it easy, and to increase the set of possible automatic refactorings? Maybe it's just a thought experiment that won't lead anywhere concrete. But to me, it's a very interesting thought experiment that I've never heard posed before.
lmm 13y ago
You're going on and on about how huge and important and valuable this insight is, like a kid saying "look how smart I am"; I suspect people are downvoting because of the tone rather than the content. Hell, the GRATUITOUS CAPITAL LETTERS in your post justify a downvote by themselves. I don't think it's a great idea. It's been tried in various ways (you assert that C# wasn't designed from the ground up to be automatically refactored, but actually easy manipulation of the code by IDEs was a key design goal - not the only goal to be sure, but a major one), and it doesn't seem to have worked. But don't let me stop you; try and build something useful out of this. I suspect you'll quickly see the problems with the idea, but if it actually works then we'll all be very grateful.
- charlieflowers 13y ago
  Ouch. Sorry you read it that way. I don't mean it as "look how smart I am." I mean it as "wow, this idea excites me." I think C# has more refactorability than most languages I've been exposed to. But I'm intrigued by the question of how much further could we go if we made that a primary goal. Granted, it's just the merest kernel of an idea, and it's an extremely ambitious one at that. Not something I'm likely to tackle on my own -- more like a thought experiment at this point. Even if it failed, the attempt would be illuminating perhaps. Anyway, thanks for leaving a comment.
  - taybin 13y ago
    I didn't read it that way. Not sure why someone showing enthusiasm would get downvoted here, but HN has a strange crowd.

deleted 13y ago

[deleted]

Helianthus 13y ago

There is a reason there are so many languages extant. They each serve a purpose. What exactly do you think you're on to? Insight has built all of the things that you're hoping to replace. So what are you bringing to the table?

charlieflowers 13y ago
> Insight has built all of the things that you're hoping to replace. Who/what is "insight"? I didn't follow this sentence. > So what are you bringing to the table? If this has been done or thought out before, possibly nothing. But I'd be OK with that, because I'd be excited to see the results. If you have a link or a search term, please pass it on.

chipsy 13y ago

Here's my question. What does "ground up" buy you? It is ideologically good, for sure. But it requires a viewpoint about future programming that is similar to existing programming: we'll write systems that are hard to maintain and are burdened with a lot of code doing relatively low-level data manipulations whose implementation can be automated. But if our future programming environments are "smaller and sleeker" in all respects(as is anticipated by, for example, the VPRI work on STEPS) this would be the wrong optimization to make. The cost of maintenance will go down across the board because the new languages let us express the change with less effort, and then complicated refactoring becomes less necessary again. (Counterpoint: We just build even more complex systems and then need better refactoring tools. An endless cycle...)

charlieflowers 13y ago
I love a lot of the principles behind VPRI and STEPS. But it strikes me as a very futuristic ideal, not something we're close to being able to use concretely and productively today. And I get the irony! The exact same thing is true of my post. But I think I'm not trying to shoot as high as you are. If we can find a way to make the VPRI/STEPS vision a reality, I'm all for it. I think what I'm proposing is a less ambitious interim step.

danieldk 13y ago

I still believe I'm on to something. I didn't vote at all, but you state: In other words, the original language has to capture more of the programmers intent (probably by inferring most of it). But I think that your comment fails to provide (1) an argument why homoiconic languages such as Lisp and Prolog do not fit the bill, since they are easy to rewrite (code is data); and (2) how this hypothetical language differs over languages that are easy to parse and have simple semantics, such as Java and C#, if most of the intent needs to be inferred. I'd rather like to see better libraries for e.g. Java (Groovy provides the REPL :)) to do this, than yet another language.

charlieflowers 13y ago
(1) Homoiconic languages are actually a smaller scale instance of exactly what I'm talking about. They were designed from the ground up to allow for compile-time code rewriting, and because that was the primary driving goal from the start, they have amazing code rewriting capabilities that other languages cannot begin to dream of. But the distinction I was trying to draw is that I'm talking about going further with that idea. Homoiconic syntax only allows for local code re-writing, but there are many other kinds of things we'd like to programmatically transform on a large codebase. Half-baked examples: We'd like to replace all use of new/delete with smart pointers, but only in source files that are in one particular section of the codebase. Or we'd like to move all our unit tests from being in a separate package/dll, to being included in the same dll but surrounded by compiler pragmas. (2) How the language would differ -- I don't yet know. But just as homoiconicity says "let's allow our end goal of automatic code rewriting to dictate our syntax", what I'm trying to say is, "let's allow our end goal of automatic refactorability / transformability to dictate all the programming language design decisions we make." I think probably many of the things Raphael_Amiard mentions in this thread would be a part of it: strong inferred typing, perhaps, and a strong package system. Perhaps the ability to write some kind that was intentionally agnostic about how it would be packaged, and write some code elsewhere that says "take that code over there, and package it thusly." It would need to know if certain snippets were functionally pure (sort of how D does with "pure nothrow"), because then it would know it have more freedom with how it could transform that code. Hopefully that clarifies the idea. It's hand wavy and high level, but it's a new (to me) idea that's only at the hand wavy stage so far.

haberman 13y ago

If you are serious and passionate about this idea, I recommend digging in deeper and thinking of more specific examples of how you can improve on the status quo. You say that you want to design from the ground up to be more transformable than anything else, but without specifics this is just a goal, and it's not clear that a new language is necessary or would buy you anything. For example, take your idea about wanting to be able to replace all instantiations with a function call instead. There's no need to invent a new language for this; the AST of a program in most any language would have enough information to write this refactoring capability into a tool. The hard part would be expressing the refactoring itself; how do you specify exactly the pattern you are trying to match, and exactly what you want to rewrite it to, in a way that is easy to use? Maybe some other ideas you have would require a new language, but it's hard to say unless you are more specific about what you want. You might find that a lot of your ideas are implementable on top of existing systems. Designing "from the ground up" has a certain appeal to it, but to justify the extreme amount of effort a new language would take, I think you'd want to be more specific about what the clean break would buy you.

charlieflowers 13y ago
Thanks for the comment. I agree that the AST of a program provides the raw material that could empower these kinds of transformations. But certain language features make it hard (like the C preprocessor, to cherry pick an example). And I guess I'm exploring the question: What would a language look like whose goal was to make it easy, and to increase the set of possible automatic refactorings? Maybe it's just a thought experiment that won't lead anywhere concrete. But to me, it's a very interesting thought experiment that I've never heard posed before.

lmm 13y ago

You're going on and on about how huge and important and valuable this insight is, like a kid saying "look how smart I am"; I suspect people are downvoting because of the tone rather than the content. Hell, the GRATUITOUS CAPITAL LETTERS in your post justify a downvote by themselves. I don't think it's a great idea. It's been tried in various ways (you assert that C# wasn't designed from the ground up to be automatically refactored, but actually easy manipulation of the code by IDEs was a key design goal - not the only goal to be sure, but a major one), and it doesn't seem to have worked. But don't let me stop you; try and build something useful out of this. I suspect you'll quickly see the problems with the idea, but if it actually works then we'll all be very grateful.

charlieflowers 13y ago
Ouch. Sorry you read it that way. I don't mean it as "look how smart I am." I mean it as "wow, this idea excites me." I think C# has more refactorability than most languages I've been exposed to. But I'm intrigued by the question of how much further could we go if we made that a primary goal. Granted, it's just the merest kernel of an idea, and it's an extremely ambitious one at that. Not something I'm likely to tackle on my own -- more like a thought experiment at this point. Even if it failed, the attempt would be illuminating perhaps. Anyway, thanks for leaving a comment.
- taybin 13y ago
  I didn't read it that way. Not sure why someone showing enthusiasm would get downvoted here, but HN has a strange crowd.