New Eiffel Technology Community - getting started
by Thomas Beale (modified: 2011 Feb 25)
I am leading a workshop on Monday 27 June 2011, at TOOLS 49 in Zurich on the idea of developing a worldwide New Eiffel Technology Community. The idea is that languages that survive like Java and Ruby today don't depend on the qualities of the language, but on the qualities of the 'technology stack', i.e. the overall ability to build large-scale systems from large reusable components, and easily deploy them. See https://wiki.se.inf.ethz.ch/nec/bin/view/Main/WebHome for details. Please consider joining the mailing list and publicising the event to others.
You're exactly right Thomas. And, perhaps as a result, the number of programmers. Or the number of programmers might be the cause, but that can perhaps be established with some historical digging.
PS: people who click on your link get "he site's security certificate is not trusted!"...
bettercodes.org
Thomas,
thanks for setting up the NETC project! I think it is a great idea for bringing Eiffel a few steps forward in terms of recognition in the developer community. I recently discovered a new service for open source developers that is currently being established at www.bettercodes.org. Having read your initial analysis on the NETC project I wonder if this new service would fit as a basis for NETC especially when taking into account what you've written about the social component of the project.
What do you think about this?
Best regards
Jens Siebert
First of all congratulations and best wises for yours furthers days. Most of the company has become worlds top technology company or community and I hope this community or company also would be there. If the any company has become a famous and no.1 then, it must be by their own efficient programmer and developers. Because of their flexibility to their own co-worker will might be the 1st reason on my view. To get goal of achievement there could be more than more secret on behind its. So, we have to fix that the way to get it. I am not a professionally some kind developer and programmer. Even I have a little bit experiences about this. To make a one of the great companies or community there must be rolled of their worker or users. I hope this will be useful to you.
Eiffel Workshop attendance
I am looking forward to attending the Eiffel Workshop [see above] to discuss the issues that Eiffel implementers have so far ignored, or inadequately addressed, that are effective road-blocks [or at least road humps] to new opportunities for expanding its usage.
Looking through the e-mail history at 'https://lists.inf.ethz.ch/mailman/listinfo/netc', many of my issues are being thought of, and will be on the agenda in Zurich.
I have been working (slowly ...) to develop tools, written in Eiffel, that are directly useful to developers in other languages, to showcase the capabilities of Eiffel and existing Eiffel libraries.
In particular, I am still preferentially using a multi-window text editor called Code Crusader, written in C++ [from NewPlanet software] because it provides so much better facilities than anything else that I have so far come across, including EiffelStudio. That needs to change.
There should be development / editor / browsing / project-generation facilities, written in Eiffel, that showcase the best that can be achieved, providing multi-language support, and Free-software licensed.
Apart from some widely useable project to get Eiffel's capabilities noticed, I also [as an ex C-programmer] have some issues with Eiffel implementation(s).
While I appreciate, and mostly agree with, the reasons for regarding manipulation of data using POINTERs as to-be-avoided or constrained in isolated clusters, to write an equivalent of PostgreSQL or btrfs directly in Eiffel is unlikely to be performance comparable because so much such data manipulation requires routine calls rather than 'built-in' features.
Eiffel is a compiled language (mostly) and is competing for mind-share against other compiled languages, and whereas performance is generally not super-critical for scripting and dynamic languages, for implementers of systems in compiled languages performance is critical, with Google considering a 1% regression being unacceptable.
The attitude, which I recognize, that 'if you are going to have to write large chunks of code in C/C++ to reach required performance goals then using another language [Eiffel] for a minority of the code is seriously problematic' is a large road hump.
How one gets over that hump is a substantial part of the process of persuading existing C/C++ writers to consider Eiffel as a realistic alternative for compiled code.
One thing I note in performance comparisons, is that the Gobo Eiffel compiler processes the Eiffel source code and generates the C intermediate code MUCH faster than gcc compiles the result; there should be an opportunity to use the LLVM infrastructure to compile Eiffel, C and other languages to LLVM and provide better functionality and performance than existing programming systems.
Food for thought and I encourage others to contribute, either at the Eiffel Workshop on June 27th or via the e-mail list 'https://lists.inf.ethz.ch/mailman/listinfo/netc' or the wiki [see earlier posts]
Howard