If something is unknowable, then the Smalltalk IDE cannot know it.
What you're missing is that there is no real static analysis phase in Smalltalk because writing a program is manipulating a running image. As soon as you write the method, it's available in your image, with all of the AST-reflective goodness that that implies.
What Eclipse does -- what I believe you're saying is what's only possible with static analysis of source code -- is to compile chunks of source code into an AST which the editor knows how to query and manipulate. Because there are some static type guarantees, you can perform flow analysis and various type algebras to prove or disprove certain theorems about the code.
What Smalltalk does is to compile chunks of source code into an AST (or bytecode or an intermediate representation or however the particular implementation does it) and graft that directly into the running image itself. The IDE is part of your program is part of the environment (the image). Now there are certain things which are completely undecidable, but the same dispatch mechanism which resolves a call to a method at runtime lets you resolve a call to a method at analysis time, because you have the same information available.
As for technical details of how that works, I'd have to finish reading the Smalltalk implementation book or the Strongtalk papers, as I'm not 100% sure how to integrate a JIT with such a system. I'm not going to guess at how they work as if I were an expert on the implementation.
You say its always runtime, but thats clearly an exaggeration at minimum, and just being snarky (in your words) at worst.
For someone who admittedly doesn't know much, if anything, about Smalltalk, you're certainly quick to tell people what Smalltalk can and can't and does and doesn't do. Please feel free to do your own research.
Not to mention fancy stuff like walk up the call hierarchy, do refactorings, do renames, etc.
I don't know enough about pre-1980 Lisp to know for sure, but I do know that Smalltalk could do all of these things before Oak was even a glint in Gosling's eye and when Eclipse was still VisualAge.
Well, thank you for not reading what I wrote at all.... If you dont know the answer, its okay to say so.
Put your snark back in the can. Your assumptions are showing.
However, at design time, the state is completely non-deterministic (or at least trivially can be)...
The Smalltalk IDE is part of a running Smalltalk image. Your program modifies the image in place. There is no distinction between design time, compile time, and run time.
Therefore, at runtime, there is one and only one state, so the outcome is easily determined.
Given that, how does the Smalltalk IDE/compiler determine whether the new/modified method is there during design-time, given that its a conditional runtime modification?
The same way that the runtime determines whether the new/modified method is there.
The result is that its IMPOSSIBLE for the IDE or compiler or static analysis tool to know whether a method exists, or I've passed the right number/type of parameters in.
One nice thing you can definitely say about Java as a language is that code that is poorly written in Java is easier to read than code that is poorly written in Python or PERL.
That's a silly comparison. No one writes code in PERL. It's a joke language.
For me, the biggest improvement from Perl 5 to Perl 6 is the ability to just call on external library functions. If I understand Perl 6 correctly, you need only do the Perl 6 equivalent of "#include " and then you can call.
That's one of our Google Summer of Code projects, actually.
it is very difficult to write unreadable code in python, for two key reasons:
Neither of those two key reasons were consistent naming conventions, good factoring, short methods, logical encapsulation, intelligent use of domain concepts, high-level documentation, a comprehensive automated test suite, or any of a dozen other features which have much more to do with maintainable code than enforced indentation, which programs such as tidy can solve for other languages trivially.
I'll raise you a counterpoint: variables which spring into existence automagically. That is not my favorite feature of Python.
95% of users won't want to change this behavior, and those who do won't have any trouble figuring out defaults write anyway.
I'm not sure that you can call a feature "discoverable" if you have to play "guess the combination of terms in your favorite search engine" to figure out if it even exists.
... accessible through GConf...
That's very nearly the last word I'd ever use to describe GConf. Are you sure you didn't mean "soul-suckingly unusable"?
A pound a week is definitely doable, and running two miles a day isn't a huge amount of exercise, if you're in reasonable shape. (If you're between 5'10" and 6'1", then 170 pounds is probably reasonable shape.)
Are you sure? Reducing your intake by 250 calories a day and burning an extra 250 calories per day from exercise will take off a pound a week. That's reasonable.
... unless his time is actually worth less than $50 per hour. I don't make even close to that much...
Think of it as a consulting rate. In that case, you'd have to pay self-employment tax, health insurance, electricity, office space rent, and other incidental costs that your employer now pays. Your time may indeed be worth $50 an hour.
Slashdot Mirror
I'll say. The magic glitter Python sugar unicorns never refactor my Perl programs for me. Jerks.
Because I took the time to learn Perl.
That depends what $foo contains. What if it ended with a single backslash?
What you're missing is that there is no real static analysis phase in Smalltalk because writing a program is manipulating a running image. As soon as you write the method, it's available in your image, with all of the AST-reflective goodness that that implies.
What Eclipse does -- what I believe you're saying is what's only possible with static analysis of source code -- is to compile chunks of source code into an AST which the editor knows how to query and manipulate. Because there are some static type guarantees, you can perform flow analysis and various type algebras to prove or disprove certain theorems about the code.
What Smalltalk does is to compile chunks of source code into an AST (or bytecode or an intermediate representation or however the particular implementation does it) and graft that directly into the running image itself. The IDE is part of your program is part of the environment (the image). Now there are certain things which are completely undecidable, but the same dispatch mechanism which resolves a call to a method at runtime lets you resolve a call to a method at analysis time, because you have the same information available.
As for technical details of how that works, I'd have to finish reading the Smalltalk implementation book or the Strongtalk papers, as I'm not 100% sure how to integrate a JIT with such a system. I'm not going to guess at how they work as if I were an expert on the implementation.
For someone who admittedly doesn't know much, if anything, about Smalltalk, you're certainly quick to tell people what Smalltalk can and can't and does and doesn't do. Please feel free to do your own research.
I don't know enough about pre-1980 Lisp to know for sure, but I do know that Smalltalk could do all of these things before Oak was even a glint in Gosling's eye and when Eclipse was still VisualAge.
Put your snark back in the can. Your assumptions are showing.
The Smalltalk IDE is part of a running Smalltalk image. Your program modifies the image in place. There is no distinction between design time, compile time, and run time.
Yes. That's exactly how it works.
$foo is a scalar. [bar] is a literal string. %arr is a hash. You're missing a closing parenthesis.
I guess this makes me a fake person.
The same way that the runtime determines whether the new/modified method is there.
Smalltalk can do that.
That's a silly comparison. No one writes code in PERL. It's a joke language.
Popularity of what? I've seen various statistics, and the job trends and book sales figures (for two examples) disagree with this assessment.
That's a chart of book sales figures for a given period of time. That chart leaves out a lot of factors peculiar to the business of selling books.
Ruby predates Perl 5, so that can't be true.
(Also the Perl 5 object model is a port of the Python object model.)
That's one of our Google Summer of Code projects, actually.
Neither of those two key reasons were consistent naming conventions, good factoring, short methods, logical encapsulation, intelligent use of domain concepts, high-level documentation, a comprehensive automated test suite, or any of a dozen other features which have much more to do with maintainable code than enforced indentation, which programs such as tidy can solve for other languages trivially.
I'll raise you a counterpoint: variables which spring into existence automagically. That is not my favorite feature of Python.
Awk will trade you a new sense of humor for its creaky, thirty-year-old joke.
... except for all of the professional developers and system administrators who relied on it to get their work done.
He did it out of love.
I'm not sure that you can call a feature "discoverable" if you have to play "guess the combination of terms in your favorite search engine" to figure out if it even exists.
That's very nearly the last word I'd ever use to describe GConf. Are you sure you didn't mean "soul-suckingly unusable"?
The ubiquity of pre-installed Windows is not a technical problem.
A pound a week is definitely doable, and running two miles a day isn't a huge amount of exercise, if you're in reasonable shape. (If you're between 5'10" and 6'1", then 170 pounds is probably reasonable shape.)
Are you sure? Reducing your intake by 250 calories a day and burning an extra 250 calories per day from exercise will take off a pound a week. That's reasonable.
Think of it as a consulting rate. In that case, you'd have to pay self-employment tax, health insurance, electricity, office space rent, and other incidental costs that your employer now pays. Your time may indeed be worth $50 an hour.
That seems like a safe guess.
Several hundred million Mandarin speakers probably think tonal languages are pretty easy to get used to. I suspect familiarity helps.
A few billion people.
Have you ever seen that work?
Me neither.