Oh dear. This can't go on for long. I've been in the middle of these muddles before. Say something like, "Dynamic languages have great tools and can be used to build large, long-lived systems." And you will find yourself on the receiving end of questions like the following which someone just sent me.
I can indulge these for a minute or two. The problem is they are rarely asked by open-minded people. Usually they come from the statically convinced, who just need to find a way to catch you, to allow themselves the comfort that their static languages and their tools could be the only possible methods for large systems. They need to assure themselves of being on the righteous path, and you, poor fellow, are one step away drowning in Styx.
Before I proceed let me state: I know large systems can be built statically. I've done it in more than one language. I've also done it dynamically in more than one dynamic language. Have you? Have you been part of failures in each? Yes, I have. They almost never have anything to do with the languages and the tools themselves.
That said, I prefer dynamic languages because they ease the pain when used well. On the other hand nothing eases the pain of bad projects.
"What happens in Smalltalk projects where you grow larger? Where you want to divide a system up into components, and some of those components don't exist yet?"
Well, what happens in other projects? You have a need; you have an idea to meet the need; you try it; you grow it. I guess I don't understand the question.
"How are interfaces between library and user code specified?"
Interface notations have been attempted for various dynamic languages, including Smalltalk and Lisp. There is a reason they've not really caught on, yet large systems are still developed in these languages.
Semi-formal notations, tests and other examples, documentation, good tools -- these all contribute to success. But if you are looking for some kind of a "static declaration" as they saving mechanism for large systems -- it may work for you, but I doubt you can prove they are necessary and sufficient. I have counter-examples.
"Can such interfaces be browsed in the same way if the code can't be called?"
Your question betrays your bias. "There must be some such mechanism as the one I am used to," he thinks.
Most large systems developed with dynamic languages have not used the kind of mechanism you seek. Look elsewhere.
Can we go back to arguing over WSDL vs. REST now? Face it. The history of programming is one of gradual adoption of dynamic mechanisms.
4 comments:
"The history of programming is one of gradual adoption of dynamic mechanisms."
Maybe that _ought_ to have been the case, but can you argue that it "is" (or "was") the case? Surely the rise of C throughout the 70s and 80s and then the rise of C++ represent the opposite? At the cusp of the 90s, there were several commercial Smalltalks available that were viable for the large majority of enterprise and even commercial development. For whatever reason, the early 90s were dominated by a clear choice away from things like 4GLs and pure OOP and an embrace of C++ and then Java.
I'm not just nit-picking: my feeling is that the history of software development tools is more complex than you present and it behooves those who are interested in anticipating (or making) mainstream tools to acknowledge those complexities.
C to C++ is an example of becoming more dynamic. Even though the compiler is still somewhat checking explicit type declarations.
Smalltalk is still around. Smalltalk influenced Java, which itself a more dynamic evolution of C to C++ to Java. Java almost had to exist, sociologically, in the progression toward more dynamic languages.
"For whatever reason..."
I think the reasons are technical and socialogical. Most people's computers were really small relative to the ones used by most Smalltalk and Lisp programmers of the day. Look also at Python and Ruby, which were implemented in the early 1990's -- they were simple yet slow implementations. The sociological pressure to be "C-like" remained until other techno-social shifts (i.e. the web) nearly eliminated that social pressure.
"the history of software development tools is more complex than you present"
No doubt. But the case can be made it is continuing to evolve toward the more dynamic.
> "What happens in Smalltalk projects where you grow larger? Where you want to divide a system up into components, and some of those components don't exist yet?"
> Well, what happens in other projects? You have a need; you have an idea to meet the need; you try it; you grow it. I guess I don't understand the question.
In small projects, yes. In projects which grow larger you either explore existing libraries, often not written in Smalltalk, or you break a system into components which are developed by different individuals, teams or organisations. The browser in the previous post appears strongly bottom-up, and to require the whole of the system to be available for its use. Do such tools shift the point where you have to transition from bottom-up application development to component based systems engineering, or is that not a problem you've applied them to?
> "How are interfaces between library and user code specified?"
> Interface notations have been attempted for various dynamic languages, including Smalltalk and Lisp. There is a reason they've not really caught on, yet large systems are still developed in these languages.
Lisp implementations usually have some foreign function interface to library code, though it's not standardised. Python also has good facilities, and I'm aware of two approaches in Mozilla's JavaScript - IDL based XPCOM where the types are defined outside of JavaScript, and jsffi where you specify the types in the JS code.
Most of the large systems I've worked with have both static and dynamic code, and sometimes components migrate between the two (usually dynamic to static for performance reasons, but sometimes the other way when it gets too convoluted for a static component to be sufficiently flexible); specifying these interfaces is painful and brittle.
Being able to extract such specifications based on use would be a big plus for these systems (though swig helps for existing libraries, it doesn't help the transitions). It also may mean that only one mechanism is required for specifying the API to a module as well as that of an FFI, whereas every other dynamic language I've seen uses different mechanisms for FFI libraries and libraries in the same language. In OO, you shouldn't really have to care how a function is implemented to call it - if you have an abstraction it should be consistent in its application.
Pete -
>> "What happens in Smalltalk
>> projects where you grow larger?
>> Where you want to divide a
>> system up into components, and
>> some of those components don't
>> exist yet?" Well, what happens
>> in other projects? You have a
>> need; you have an idea to meet
>> the need; you try it; you grow
>> it. I guess I don't understand
>> the question.
> In small projects, yes. In
> projects which grow larger you
> either explore existing
> libraries, often not written in
> Smalltalk, or you break a system
> into components which are
> developed by different
> individuals, teams or
> organisations.
Smalltalk supports foreign
libraries, sure.
Smalltalk "components" are called
"packages" that are versioned,
consist of one or more classes, as
well as methods that can be added
to or replace methods in other
packages. Squeak Smalltalk has the
Monticello package management
system and the Squeak Source public
Monticello repository. Cincom
Smalltalk has a similar
capability. I think Gemstone
Smalltalk has support or will soon
for Monticello.
> The browser in the previous post
> appears strongly bottom-up, and
> to require the whole of the
> system to be available for its
> use. Do such tools shift the
> point where you have to
> transition from bottom-up
> application development to
> component based systems
> engineering, or is that not a
> problem you've applied them to?
The system browser is both
bottom-up and top-down, allowing
development and exploration either
direction. Smalltalk packages are
generally expected to be delivered
with source, that is "the Smalltalk
way" and has been for over thirty
years. That does not mean to imply
everything is "bottom-up", just
that Smalltalk programmers see the
benefit in "getting to the bottom
of it" when desired.
>> "How are interfaces between
>> library and user code
>> specified?" Interface notations
>> have been attempted for various
>> dynamic languages, including
>> Smalltalk and Lisp. There is a
>> reason they've not really caught
>> on, yet large systems are still
>> developed in these languages.
> Lisp implementations usually have
> some foreign function interface
> to library code, though it's not
> standardised.
Smalltalk implementations each have
their own as well. But Smalltalk
packages just use Smalltalk, no
formal interface descriptions
separate from the classes
themselves. Smalltalk is
message-based, not interface
based. See "Duck Typing". If it
quacks like a duck, it's a
duck. REST/HTTP is the same way, so
get used to it.
> Python also has good facilities,
> and I'm aware of two approaches
> in Mozilla's JavaScript - IDL
> based XPCOM where the types are
> defined outside of JavaScript,
> and jsffi where you specify the
> types in the JS code.
Yep.
> Most of the large systems I've
> worked with have both static and
> dynamic code, and sometimes
> components migrate between the
> two (usually dynamic to static
> for performance reasons, but
> sometimes the other way when it
> gets too convoluted for a static
> component to be sufficiently
> flexible); specifying these
> interfaces is painful and
> brittle.
I am sorry. It does not have to be
that way. What was painful and
brittle for you?
> Being able to extract such
> specifications based on use would
> be a big plus for these
> systems...
Dynamic language systems tend to
rely on good tests, "tests that
teach", among other things.
> In OO, you shouldn't really have
> to care how a function is
> implemented to call it - if you
> have an abstraction it should be
> consistent in its application.
Yeah, I've heard that
somewhere. But you seem to
specifically be addressing calling
interfaces between languages. If
you want to do that there are ways
to do so in Smalltalk, Lisp,
etc. of course, whether you prefer
CORBA, SOAP, a runtime-specific
FFI, or whatever.
I use the Squeak FFI to use Linux C
libraries within Squeak. Otherwise
most integration I care about these
days is over the wire, e.g. using
REST/HTTP and XMPP. Neither of
those distributed coordination
mechanisms are statically
typed. Static typing over the wire
is even less necessary than within
an OS process.
(BTW I hope this formatting with
quotations looks ok on the
screen. Comments on blogger have
narrow columns. I used a dynamic
language system called "emacs"
which has a lot of third party
libraries to perform the editing.)
Post a Comment