3 ms·

Microsoft will still be THE MAN on the desktop and enterprise for a long time (I just switched to Mac however. Parallels rocks). And .Net is what will keep the

by djasek 20y ago

Microsoft will still be THE MAN on the desktop and enterprise for a long time (I just switched to Mac however. Parallels rocks). And .Net is what will keep them ticking. (Office too, but that's a different post. Have you seen what MindManager has done with Word?) If anyone wants to put the last nail in their coffin, build a better .Net. And do it with Lisp. .Net shows what we have needed for a long time. A consistent development platform where it doesn't really matter what language you program in. Everything gets compiled down the same way, everyone uses the same API and libraries. But the syntax is locked away and guarded (big surprise coming from a monopolist). You can't easily find it, and you sure as hell can't easily change it. And even if you do, the byte-code doesn't offer any more power than the over-language. All you can do is beg for a change, and maybe a year later you will get a watered down version. Free us from our syntax chains. You've gone on at length about how cool Lisp is. How it can be morphed into whatever language is needed at the time. So prove it. Fix .Net by describing the language syntax in Lisp. Give the end programmer the ability to see and adjust their chosen language to behave as needed on a project by project basis. And do it in a way that will actually get used. Instead of making a 100 year language, make a 100 year platform where the language can shift as the problems and fads do. It won't be easy, but it might just change the world.

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.

by djasek 20y ago

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.