Stuck besides using dynamic languages

When the fine folks at Xerox Parc in 70's invented a modern, dynamically typed, reflective and garbage collected scripting language called Smalltalk-80 they knew that thanks to Moores Law machines will become quick enough to execute it. With more quick CPUs, more RAM, faster disk-access and Virtual Machine technology of the 90’s arriving in a language near you that time has come.

Today you can build your monoliths and microservices in your favorite scripting languages (e.g. Pharo, Ruby or Python), benefit from the more quick development cycle and still have reasonable performance when running in production.


While the above is very nice, there is one catch. If you have a background in Smalltalk-80/Pharo and have to debug/analyze a problem in another language you will find yourself in the situation wondering why the tools make so little use of the language. Let me give you an example.

I have updated one of my components to work with newer versions of its dependencies and one HTTP PUT of my system tests started to fail. The system tests are executed by Jenkins and are written in python using the unittest module and tortilla to drive the REST API. The stacktrace of the failing test can be seen below.

File "../tests/system_test.py", line 119, in testCustomer
cus_prof_api('CustomerProfile').put(data={'field': 'val'})
File "/usr/local/lib/python2.7/dist-packages/tortilla/wrappers.py", line 377, in put
return self.request('put', *parts, **options)
File "/usr/local/lib/python2.7/dist-packages/tortilla/wrappers.py", line 365, in request
return self._parent.request(method=method, **options)
File "/usr/local/lib/python2.7/dist-packages/tortilla/wrappers.py", line 365, in request
return self._parent.request(method=method, **options)
File "/usr/local/lib/python2.7/dist-packages/tortilla/wrappers.py", line 191, in request
r.raise_for_status()
File "/usr/lib/python2.7/dist-packages/requests/models.py", line 825, in raise_for_status
raise HTTPError(http_error_msg, response=self)
HTTPError: 500 Server Error: Internal Server Error

To you this might seem like business as usual. You see which test failed, what data has been used but to a Pharo user this pretty much looks like a lost opportunity. My component did not only set the HTTP error code to 500 but the response included some details. But at the time I look at the stacktrace the application has exited, so how exactly do I inspect the HTTPError? For a language that comes with batteries included that seems rather disappointing.

In Smalltalk-80 and Pharo everything is an object. This includes the stack frame/activation record used when invoking a method. With the Fuel serializer/materializer I can serialize the stack frame (and everything reached from there) on test failure and materialize it on my development machine long after the application has stopped. In fact this is something that is a built-in feature of the Pharo test execution framework.

I am aware of pytest.py and options like --showlocals and --tb=style but it doesn’t seem to do the same thing. How comes there are custom test runners and the pickle module but the best way to understand the issue seems to be to get onto the test system and run the test by hand and use some curl? Am I doing it wrong or do we still need to see the full potential of dynamic languages?

A single golf clap? Or a long standing ovation?

By clapping more or less, you can signal to us which stories really stand out.