3 ms·

I'm not sure you realize the can of worms you would be opening up by feeing up the syntax chain. I agree freeing up syntax is a very viable method for imporvin

by Bogo 20y ago

I'm not sure you realize the can of worms you would be opening up by feeing up the syntax chain. I agree freeing up syntax is a very viable method for imporving codeing, but it is also very easily leads twards confusion in the minds of code maintainers. The idea is old and has been implemented a number of times, but also it has never taken off because of the major problem with what does "for (x) in Y {;;some more code here}" mean? FYI, I've implemented a flexible programming language. They are a bear to implement. I'm positive you don't want to go there. Think about this. The developer tweeks the syntax translation for the code he is working on. What happes to all the other uses of that syntax in the program?

djasek 20y ago
The appropriate use of namespaces and developer discretion would be needed to ensure you don't F up your other code. If you want a switch that checks if one string is contained in another, you don't modify the switch syntax. You make a switchContain. And you know what "for (x) in Y {;;some more code here}" means the same way you know what "x= someFunc(a,b,c)" means. You look it up. Of course it is best if the developer uses good names and comments so you can make a good guess by looking at it. Yea it's hard, and yea it's dangerous. All powerful things are. I don't like being told I can't have something because you think I am too stupid to use it safely. Some people won't be able to use it, and everyone at one point will be too inexperienced to use it correctly. But thats why you layer the more common languages on top. And if you are running an enterprise shop where you can't guarantee the quality of the maintenance developers, don't let your developers use it. etc... Because it's too powerful is not a very convincing argument for me.

3 ms·

I'm not sure you realize the can of worms you would be opening up by feeing up the syntax chain. I agree freeing up syntax is a very viable method for imporvin

by Bogo 20y ago

djasek 20y ago
The appropriate use of namespaces and developer discretion would be needed to ensure you don't F up your other code. If you want a switch that checks if one string is contained in another, you don't modify the switch syntax. You make a switchContain. And you know what "for (x) in Y {;;some more code here}" means the same way you know what "x= someFunc(a,b,c)" means. You look it up. Of course it is best if the developer uses good names and comments so you can make a good guess by looking at it. Yea it's hard, and yea it's dangerous. All powerful things are. I don't like being told I can't have something because you think I am too stupid to use it safely. Some people won't be able to use it, and everyone at one point will be too inexperienced to use it correctly. But thats why you layer the more common languages on top. And if you are running an enterprise shop where you can't guarantee the quality of the maintenance developers, don't let your developers use it. etc... Because it's too powerful is not a very convincing argument for me.