- primary: patrik.svestka [at] gmail[dot]com
- secondary: patrik.svestka [at] svestka[dot]biz
- My always incomplete Curriculum Vitae
I love to dig deep into interesting problems and try find solutions.
One should always try to find an best solution for the given time. Don’t compromise on quality because in the end it will come back to haunt you.
I love Smalltalk, but I think it needs to move out of its shadow - there were many new developments during the last 40 years and Smalltalk should reflect that.
Smalltalk has had a difficult history. First of all, it has been born way ahead of its time. It has met many obstacles (like IBM implementing it and then leaving it be) on its way but it is still alive today, but the number of programmers are diminishing.
It should be free of the chains from past that bind and seek new anwers to our problems.
- Create new Smalltalk projects
- Predictable development cycle and standardization
- The development environment must be stable - every crash should be examined and fixed
New great ideas at that time should be incorporated into the environment e.g.
- Smalltalk image update to fit the distributed development model
- use modern CVS (e.g. mercurial or git)
- support meta-programming (inspiration can be taken from LISP), etc.
- Release code and libraries under open-source license like MIT so other deveopers can contribute
- Every bug in the VM or core libraries should be fixed as a priority
- New features can be added after the VM and the core libraries are considered stable
- New features should bring improvement(s) or add some missing functionality and must not break the old code
- No tests = no merge -> Every code written should be properly tested with test cases and have documentation
- The Smalltalk community should be welcoming to the newcomers + experienced programmers should be nurtured and valued
Where to get help with Smalltalk?
If you have a question on Smalltalk don’t hesitate to ask on Stackoverflow