I have very little tolerance (or desire to use) visual programming environments, or "CASE tools", or very dynamic languages that permit "rapid prototyping".
Someone give this guy a "quick application delivery tool" that isn't a dynamic language, or a prototyping tool, or a CASE tool, and make sure it's strapped to the back of a baby unicorn.
Why do otherwise good programmers insist on being ..
He is an MLer, you can't accuse this guy of being stupid, short sighted or trendy. Yet, he is going out of his way to handicap himself. ML is a big-picture programming language: you understand everything, then you type it out. Dynamic languages are better suited for exploratory programming; you start with your algorithms solving the simplest case, then you make things more sophisticated as you go. There is nothing "prototyping" about them; the difference between my prototypes and my production code is that my production code listens on a privileged port and has a cron job watching over it.
I didn't enumerate the reasons that I don't use dynamic languages, because that would have been flame-bait territory.
I see this suggestion as a way in which static languages could be better at prototyping in the same way that dynamic languages sometimes are, so I think you noticed my (implied) assumption that there was something desirable about this idiom that is not as readily achievable using existing methods in languages like ML or Haskell.
That said, I can't see that there is any reason why what I suggest wouldn't be useful in a dynamic language, too. The implementation details just change a bit.
Even bringing dynamic languages into the conversation was an just to counter to people saying "Use ___" where ___ is one of Python, Ruby etc, which is basically a non-solution for my purposes.
If this was anybody else, I would tell them to explore alternative programming methodologies, styles, and languages. But not you gdp; you know what you're doing, so if you're hitting a dead end with interactive ML, I don't think many people can help you, you might be at a frontier here (at least I can't; I have dropped my last static language 8 years ago when I decided to have my cake and eat it too with the Lisp family.)
Well, sure, I wasn't hoping that somebody would say "this already exists and here it is" (though that might be nice) - I was saying "here's something that would improve my life". Maybe I'll even take the time to implement it one of these days!
SML, OCaml, and Haskell are all statically-typed languages with advanced REPLs, just not with the features he wants. It sounds like he want a constraint solver, among other things.
6 comments
[ 2.9 ms ] story [ 25.7 ms ] threadSomeone give this guy a "quick application delivery tool" that isn't a dynamic language, or a prototyping tool, or a CASE tool, and make sure it's strapped to the back of a baby unicorn.
Why do otherwise good programmers insist on being ..
He is an MLer, you can't accuse this guy of being stupid, short sighted or trendy. Yet, he is going out of his way to handicap himself. ML is a big-picture programming language: you understand everything, then you type it out. Dynamic languages are better suited for exploratory programming; you start with your algorithms solving the simplest case, then you make things more sophisticated as you go. There is nothing "prototyping" about them; the difference between my prototypes and my production code is that my production code listens on a privileged port and has a cron job watching over it.
I see this suggestion as a way in which static languages could be better at prototyping in the same way that dynamic languages sometimes are, so I think you noticed my (implied) assumption that there was something desirable about this idiom that is not as readily achievable using existing methods in languages like ML or Haskell.
That said, I can't see that there is any reason why what I suggest wouldn't be useful in a dynamic language, too. The implementation details just change a bit.
Even bringing dynamic languages into the conversation was an just to counter to people saying "Use ___" where ___ is one of Python, Ruby etc, which is basically a non-solution for my purposes.