If this is easy to reproduce (I'm thinking more about setup requirements), could
you submit your code to http://support.eiffel.com so that we can find out what
is
going wrong?

Thanks,
Manu

> -----Original Message-----
> From: eiffel_software@yahoogroups.com
> [mailto:eiffel_software@yahoogroups.com] On Behalf Of Berend de Boer
> Sent: Wednesday, April 18, 2012 1:16 PM
> To: eiffel_software@yahoogroups.com
> Subject: Re: [eiffel_software] Crash in once routine
>
> >>>>> "Emmanuel" == Emmanuel Stapf <manus@...> writes:
>
>     >> Could you perhaps explain what once_raise is?
>
>     Emmanuel> This is internal code, but the idea is that when you
>     Emmanuel> have an exception during the evaluation of a once, next
>     Emmanuel> time you call that once it will repeat the exception, in
>     Emmanuel> other words, once an exception always an exception. That
>     Emmanuel> routine is what raise the exception that has once
>     Emmanuel> occurred.
>
> Right. Extremely weird. I replaced the code by the poor man's once per
> object, and it works perfectly.
>
> --
> All the best,
>
> Berend de Boer
>
>
>           ------------------------------------------------------
>           Awesome Drupal hosting: https://www.xplainhosting.com/
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

On 18 Apr 2012, at 21:44, Thomas Beale wrote:

> Assuming we do something about this whole idea, we need to make
> something simple work,

I agree with making this simple, but balance it with flexibility. It should be
simple flexibility.

> and the one thing most goal-oriented people hate

aside do: I worry about these goal-oriented people. They are living under an
illusion. As John Lennon quoted "Life is what happens when you are making other
plans". Goal-oriented people are those who pretend the world doesn't change
around them and their view of the world is correct (when it isn't). Software
must be quickly changeable for the changing world. DbC addresses that. I usually
find myself in arguments with G-O people because their emphasis is on writing
huge plan documents and not being agile. Then when their goals change, they
blame the software people. So I don't think G-O people should be used as a good
justification for anything! I lent Bertrand's book Object Success to one such
person I worked with. He really liked it, but did not really get the point, even
though my copy was heavily underlined at relevant places. end -- aside

> is choices in the tools they are using. So we need to create completely
> built language skins for normal users. But, it is certainly worth
> thinking about offering a way for language hackers to configure some or
> all of the syntax preferences.

You are right though, one thing people don't want to have to do is spend hours
setting up things before they can do useful work. (1) I think we have the cake
and eat it as well. At the lowest level everything is configurable with
preferences, but the first thing in the preferences panel is a drop down menu to
choose C-like, Eiffel (default), Java, etc. Then if the user changes any of the
other items, they can store it as their own configuration. So I think skins is
like Bertrand said another name for style sheets (perhaps that's another
misnomer too, why is it a sheet?) On the other hand, perhaps a few pre-built
skins could do it, but I don't think flexibility of every parameter would be
particularly difficult.

Note 1. { Maybe this is a bad thing. Programmers don't seem to have the patience
to learn the craft of programming or their tools before inflicting their bad
programs on the world. Parnas makes a point (I think I have already stated it)
that the 'software crisis' is not due to lack of programmers, it is due to lack
of quality programmers. }

> This flexibility would need to be
> balanced against making even the simplest implementation of this idea
> too complex to actually do right now. But it's certainly something we
> should keep in mind.

I'm always a little wary about suggesting just doing what will cover the current
specific situation, ignoring the general solution which would be simple to do up
front, but difficult to retrofit later. (Although my line here is very open to
debate.)

>
> - thomas
>
> On 18/04/2012 02:56, Ian Joyner wrote:
>>
>> Rereading this proposal now, I think the case for roll-your-own
>> language in the editor is a better way to go. Thomas has identified
>> that C people have a (perverse) 'preference' for C syntax. Thus syntax
>> is a matter of preference. Preferences are handled in preference panels.
>>
>> A simple preference would be, if I type /= or != this becomes the ≠
>> character (I hope that displays as not equals). If I type := or =
>> (just after a lvalue) I get a left arrow.
>>
>> A more complex preference is do I want boolean expressions in ifs,
>> loops, etc wrapped in (<be>) or a 'then' terminating it. I'd prefer
>> typing 'then' - it's quicker. Open and close parens needs move left
>> hand off alphabetic keys, hold down shift, move RH off alphabetic keys
>> and press the '9' key, later move LH off again to hold down shift,
>> move RH again off alphas, press '0'. Aside from the fact that parens
>> are getting more and more abused by people not putting space before
>> and after and putting space inside instead. This completely lacks any
>> taste, and I believe if and where space is put should be a preference,
>> so when I type '(', an en-space is automatically put before it, so
>> that any routine name sticks out.
>>
>> Thus store the program in some intermediate form, albeit text, and yes
>> format with style sheets (but nothing as horrible as CSS!)
>>
>> Ian
>>
>> On 18 Apr 2012, at 00:52, Bertrand Meyer wrote:
>>
>>>> I think that actually doesn't matter. The goal was to use Eiffel to
>> communicate with people who have no intention or desire to use
>>> Eiffel.
>>>> Making it so complete that you can actually use it for writing code
>> is undesirable IMO.
>>> I don't think this would go anywhere. The effort is only worth
>> pursuing if the result is going to be fully functional; if there is
>>> something that can be done in Eiffel but not in Javel people will
>> dismiss the idea as a joke and it will cause only harm. Thomas
>>> Beale expressed this well by suggesting the notion of "skin".
>>> Another way to think about it is style sheets, as in CSS. The
>> semantics remains the same, the presentation changes.
>>> For me the principles (expanded a bit from the document of
>> yesterday, http://bit.ly/IzAdCo, I am updating it now, if Yahoo messes
>>> the formatting below please look up the text there) should be:
>>> 1. Full semantic equivalence
>>> -- The full semantics of Eiffel is still available, simply under a
>> different syntax.
>>> 2. Minimality of changes
>>> -- The difference between Eiffel and Javel is characterized by a few
>> transformation rules,
>>> -- in the style of those of http://bit.ly/IzAdCo.
>>> 3. The set of reserved words is the same in all versions
>>> -- This is slightly less restrictive than "no new keywords" as
>> originally stated.
>>> -- It makes it possible to add keywords, but they should become
>> Eiffel keywords
>>> -- as well. Adding shortened keywords like `req' would only cause
>> trouble.
>>> -- Obviously very few keywords if any will be added.
>>> With these principles it should be possible for EiffelStudio and
>> other tools to provide a simple switch.
>>> If you agree with these principles it would be great if one of the
>> contributors to this discussion took the lead, formed a small
>>> working group, and came back in two or three weeks with a proposed
>> design.
>>> -- BM
>>> (About the name: http://fr.wikipedia.org/wiki/Eau_de_Javel)*
>> *
>>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Something that prompted a thought in Thomas's post and that came out of
Bertrand's thought about not changing the semantics of Eiffel.

The semantics of Eiffel are well documented, and probably even better documented
in material that Bertrand has. All syntax should be removed and a programming
system built around that. As we have said with syntax of choice.

The idea that popped into my head was HyperCard. This simple end-user
programming system was developed by Bill Atkinson at Apple mid 80s. It was based
on the simple event handling 'on'. JavaScript was inspired by this. Each on
event handler was bundled in it's own little script. (That had a downside that
it was hard to reason about the whole system.)

My reasoning yesterday was that a system is a set of definitions and
syntactically that suggested putting the keyword first followed by its type
definition. Thus at any level a system can be inspected by viewing available
keywords within a context (this may help solve the namespace problem as well,
which is a raging debate on Apple's Objective-C list at the moment). This could
be analogous to code folding and unfolding in an editor, but I really think
something a bit deeper than that.

It could be that a visual viewer like BON (UML ugh) is used at the top level.
That makes me think that all the elements are already there. They just need
rearranging a little.

Ian

I think you are right. Most languages and IDEs are free. Adding to the list of
Xcode (which people love or hate), Eclipse, MS studios, NetBeans, is Python and
Ruby.

While making Eiffel completely free, I don't think that will solve the problem
of getting Eiffel widely adopted. NeXT and then Apple charged $50,000 for
WebObjects. WebObjects was and still is the ultimate web development system out
there. It was used by some enthusiastic developers, including one called Dell
that built a distribution mechanism and hence the company on WO. Then Apple
dropped the price to $500 in 2000. A few years later, they made it totally free,
but had missed the boat. Oh, and they also changed the syntax (language) from
Objective-C to Java, I think mainly to make it cross platform.

So I think making Eiffel free may be a necessary precondition, but it is not
enough to ensure the outcome.

Ian

On 18 Apr 2012, at 22:55, Steven Boyls wrote:

> As someone stated earlier it seems that the best way to do so would
> have an item in the preferences section where the user could choose
> syntax styles such as:
> 1.) C/C++ syntax
> 2.) Java Syntax
> 3.) PHP
> 4.) Insert your favorite here
>
> Of course, Eiffel is the default. You have have to determine the extent of
> support for the syntax options. Is it just a matter of using /= vs. !=, { }
vs. Begin - End.
> Do you also change the order of variable declaration? <variable_name> <TYPE>
vs. <TYPE> <variable_name>.
>
> Keywords should not change.
>
> If it is a matter of growing the language user base then maybe this is a moot
point. I think
> it is a different matter. For example, Apple include the Xcode IDE free with
the Apple installation
> disk. Netbeans and Eclipse are freely available off the internet.  You can
even get a free download of the MS SDK.
> You are free to produce commercial code with the all of the above IDE's and
SDK's. I personally think a big
> barrier is the price tag that comes with the Eiffel IDE if you want to develop
commercial software.
> As a freelance software engineer I write software to make a living. As a
businessman I have to manage my
> costs so I look to the languages that provide most of what I need at the best
price. Many of the C/C++/Java IDE's
> are free. My clients don't care what language I use as long as I create
applications that run as expected.
> There are many people who use the same logic as myself. How many people knew
much about Objective-C
> before Apple created the AppStore and provided a way for developers to create
apps for the iPhone? Apple does
> not make a penny off the sale of the IDE. They make millions of dollars by
providing the framework to sell the apps.
> Maybe the people at Eiffel should consider something similar. Instead of an
iPhone or iPad maybe it's an EiffelPhone
> or EiffelPad.
>
> Food for thought.
>
> Steve
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

I would very much appreciate help with the following BON question.

Suppose I show my root_cluster with its classes on the drawing tool. One of
the classes in this cluster inherits from a class in the base_cluster (e.g.
class ITERATOR[G]). I find ITERATOR somewhere in base and pick and drop it
onto the drawing canvas. But nothing happens.

What I would expect would be to see just the class ITERATOR in its
base_cluster with an inheritance arrow to it from my class in root_cluster.
How do I achieve that? Thanks in advance.

Jonathan Ostroff

Hello,

I try to migrate my code to void-safety.

My classes are compiled with options:
- on demand void-safety
- types attached by default.

Some non-void-safe libraries (like GOBO) have options:
- no void-safety
-

In class ISQL_COMMANDS (void-safe on demand, attached by default), the following
feature


	 new_cursor : DS_LIST_CURSOR [ISQL_COMMAND] is
		 do
			 Result := commands.new_cursor
		 end

exhibits the following error:

<quote>
		 Error code: VJAR

     Type error: source of assignment is not compatible with target.
What to do: make sure that type of source (right-hand side)
   is compatible with type of target.

Class: ISQL_COMMANDS
Feature: new_cursor
Target name: Result
Target type: DS_LIST_CURSOR [ISQL_COMMAND] (from clisql)
Source type: [detachable] DS_LIST_CURSOR [ISQL_COMMAND] (from clisql)
Line: 85
       do
->      Result := commands.new_cursor
       end
</quote>

I understand why the result of commands.new_cursor is not "attached".
BUT
when I read the DS_LIST.new_cursor feature I see the postcondition:

		 ensure -- from DS_TRAVERSABLE
====> 	 cursor_not_void: Result /= Void
			 valid_cursor: valid_cursor (Result)
		 end

So i dare to propose a new nCAP (nearly-Certified Attachment Pattern) :

AIM: ease the transition to void-safety
PROPOSAL:
- a query whose result is guaranteed "not void" by a postcondition is considered
as "attached" to clients.
- A warning is issued to encourage migration of non-void-safe providers.


What do you think ?
It would help **a lot**

Best regards,

Paul G. Crismer
Technical Manager/Development Methods and Tools
Group S - Belgium

You have defined `new_cursor' as attached (e.g. new_cursor: DS_LIST_CURSOR
[ISQL_COMMAND] <-- is an attached type).
The body of the routine needs to use a CAP (Certified Attachment Pattern) to
achieve a conforming match.
The result of `commands.new_cursor' is not attached. So, two basic solutions
are:
1. Look at the Result of `commands.new_cursor' and ensure the attachment
there.2. Apply a CAP to the `Result := commands.new_cursor':
do   if attached commands.new_cursor as al_cursor then       Result := al_cursor
else       check not_attached: False   endend
Alternatively,
do   check attached_cursor: attached commands.new_cursor as al_cursor then     
Result := al_cursor   endend
The second version is more compact and accomplishes the same goal: Either an
attached Result, conforming to the attached type of the feature Result or a
check assertion failure.
In our shop, we refer to this as a `check attached', which is a CAP. The
compiler will now be able to see by way of the CAP that Result will never be
Void (e.g. Void-safety).
Hope this helps!
Cheers!Larry

To: eiffel_software@yahoogroups.com
From: paul-georges.crismer@...
Date: Thu, 19 Apr 2012 08:47:48 +0000
Subject: [eiffel_software] A new CAP for helping migration towards void-safety
... ?


























       Hello,



I try to migrate my code to void-safety.



My classes are compiled with options:

- on demand void-safety

- types attached by default.



Some non-void-safe libraries (like GOBO) have options:

- no void-safety

-



In class ISQL_COMMANDS (void-safe on demand, attached by default), the following
feature



	 new_cursor : DS_LIST_CURSOR [ISQL_COMMAND] is

		 do

			 Result := commands.new_cursor

		 end



exhibits the following error:



<quote>

		 Error code: VJAR



Type error: source of assignment is not compatible with target.

What to do: make sure that type of source (right-hand side)

   is compatible with type of target.



Class: ISQL_COMMANDS

Feature: new_cursor

Target name: Result

Target type: DS_LIST_CURSOR [ISQL_COMMAND] (from clisql)

Source type: [detachable] DS_LIST_CURSOR [ISQL_COMMAND] (from clisql)

Line: 85

       do

->      Result := commands.new_cursor

       end

</quote>



I understand why the result of commands.new_cursor is not "attached".

BUT

when I read the DS_LIST.new_cursor feature I see the postcondition:



		 ensure -- from DS_TRAVERSABLE

====> 	 cursor_not_void: Result /= Void

			 valid_cursor: valid_cursor (Result)

		 end



So i dare to propose a new nCAP (nearly-Certified Attachment Pattern) :



AIM: ease the transition to void-safety

PROPOSAL:

- a query whose result is guaranteed "not void" by a postcondition is considered
as "attached" to clients.

- A warning is issued to encourage migration of non-void-safe providers.



What do you think ?

It would help **a lot**



Best regards,



Paul G. Crismer

Technical Manager/Development Methods and Tools

Group S - Belgium


















[Non-text portions of this message have been removed]

I apologize for the poor formatting. Apparently, my email program via
the web does a terrible job and the formatting gets junked as it goes
into Yahoo.
Let's try this again:
doif attached commands.new_cursor as al_cursor thenResult :=
al_cursorelsecheck is_attached: Falseendend
Alternatively,
docheck attached_cursor: attached commands.new_cursor as al_cursor
thenResult := al_cursorendend

--- In eiffel_software@yahoogroups.com, LARRY RIX <ljr1981@...> wrote:
>
>
>
>
> You have defined `new_cursor' as attached (e.g. new_cursor:
DS_LIST_CURSOR [ISQL_COMMAND] <-- is an attached type).
> The body of the routine needs to use a CAP (Certified Attachment
Pattern) to achieve a conforming match.
> The result of `commands.new_cursor' is not attached. So, two basic
solutions are:
> 1. Look at the Result of `commands.new_cursor' and ensure the
attachment there.2. Apply a CAP to the `Result := commands.new_cursor':
> do   if attached commands.new_cursor as al_cursor then       Result :=
al_cursor   else       check not_attached: False   endend
> Alternatively,
> do   check attached_cursor: attached commands.new_cursor as al_cursor
then      Result := al_cursor   endend
> The second version is more compact and accomplishes the same goal:
Either an attached Result, conforming to the attached type of the
feature Result or a check assertion failure.
> In our shop, we refer to this as a `check attached', which is a CAP.
The compiler will now be able to see by way of the CAP that Result will
never be Void (e.g. Void-safety).
> Hope this helps!
> Cheers!Larry
>
> To: eiffel_software@yahoogroups.com
> From: paul-georges.crismer@...
> Date: Thu, 19 Apr 2012 08:47:48 +0000
> Subject: [eiffel_software] A new CAP for helping migration towards
void-safety ... ?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>       Hello,
>
>
>
> I try to migrate my code to void-safety.
>
>
>
> My classes are compiled with options:
>
> - on demand void-safety
>
> - types attached by default.
>
>
>
> Some non-void-safe libraries (like GOBO) have options:
>
> - no void-safety
>
> -
>
>
>
> In class ISQL_COMMANDS (void-safe on demand, attached by default), the
following feature
>
>
>
>  new_cursor : DS_LIST_CURSOR [ISQL_COMMAND] is
>
>   do
>
>    Result := commands.new_cursor
>
>   end
>
>
>
> exhibits the following error:
>
>
>
> <quote>
>
>   Error code: VJAR
>
>
>
> Type error: source of assignment is not compatible with target.
>
> What to do: make sure that type of source (right-hand side)
>
>   is compatible with type of target.
>
>
>
> Class: ISQL_COMMANDS
>
> Feature: new_cursor
>
> Target name: Result
>
> Target type: DS_LIST_CURSOR [ISQL_COMMAND] (from clisql)
>
> Source type: [detachable] DS_LIST_CURSOR [ISQL_COMMAND] (from clisql)
>
> Line: 85
>
>       do
>
> ->      Result := commands.new_cursor
>
>       end
>
> </quote>
>
>
>
> I understand why the result of commands.new_cursor is not "attached".
>
> BUT
>
> when I read the DS_LIST.new_cursor feature I see the postcondition:
>
>
>
>   ensure -- from DS_TRAVERSABLE
>
> ====>   cursor_not_void: Result /= Void
>
>    valid_cursor: valid_cursor (Result)
>
>   end
>
>
>
> So i dare to propose a new nCAP (nearly-Certified Attachment Pattern)
:
>
>
>
> AIM: ease the transition to void-safety
>
> PROPOSAL:
>
> - a query whose result is guaranteed "not void" by a postcondition is
considered as "attached" to clients.
>
> - A warning is issued to encourage migration of non-void-safe
providers.
>
>
>
> What do you think ?
>
> It would help **a lot**
>
>
>
> Best regards,
>
>
>
> Paul G. Crismer
>
> Technical Manager/Development Methods and Tools
>
> Group S - Belgium
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>



[Non-text portions of this message have been removed]

All,

for those interested in a concrete proposal leading to an
implementation, please see this page I have set up -
http://dev.eiffel.com/Eiffel_Language_Skins . I am happy to try to act
as a facilitator for this activity, and accordingly I created a rough
framework for considering the problem. My suggestions for proceeding are
as follows:

   * if you want to actually contribute, please use the page above and
     its discussion page(s) to do this, and set a 'watch' on the main page
       o if you violently disagree with the way I have set out the
         problem on this page, please feel free to say so on the
         discussion page, and we can discuss alternatives
       o if you have a personal proposal that you particularly want to
         post as a reference, please follow the instructions in the page
         to do with creating a new page for your ideas and setting a link
         to it (I know many people have thought about ideas around this
         subject in the past)
       o otherwise, we will use the discussion pages to crystallise out
         directly a set of rules and implementation ideas for Javel.
   * it you just want to follow, set a 'watch' on the main page

Please note that I have not had time to go through all the voluminous
posts here on this list, so if your great ideas are not yet on the page,
please put them there or link to your posts etc.

On the name Javel: we have not decided on any final name, but this
suggestion from Bertrand is easy to pronounce, and I think we should use
it as a working name for now.

Last note: this is not intended as an open-ended theoretical or academic
exercise. We are really looking at if & how a friendly (to C-syntax
lovers) skin could be put on tools like EiffelStudio and any other
compiler, that would enable those people to use Eiffel but see it
through a syntax they understand. Consequently I have defined an initial
timeline!

- thomas beale



[Non-text portions of this message have been removed]

Hello,

I'am astonished by the vitality of the discussion about "Javel".
Never thought syntax was of any attracting/repulsing relevance.
The syntactic diversity of new 'sexy' languages, enforces my opinion.

In my eyes, providing other skins to Eiffel is "nice-to-have".

More attractive to developers is what Larry Lix spoke about in his post
(http://tech.groups.yahoo.com/group/eiffel_software/message/19183.
1- frameworks, from the simple to the complex and from general to comprehensive
2- address real-world needs of creating well crafted software
3- ease of use and Rapid Application Development (how quickly and easily can I
deliver to my client?)
4- advertise the "Eiffel advantage" : Void-safety, DBC, Agents, SCOOP...

#1 and #2 should give testimony that Eiffel is not a "university" or research
language.

#2 and #3 would give some assurance to developers (provide applications to
clients) and to managers (it's worth the money).

I would also add some other topics like:
- review and enhance the user experience of EiffelStudio
- make documentation sexier and available (I know people who think Eiffel is a
nearly died language because there apparently is no documentation, and the
community -i.e. chances to get help- is so tiny)
- publish tutorials about nowadays real world needs (the dining philosophers is 
of no immediate interest) for dummies :
   - retrieving data from a database
   - developing a first webservice
   - reading an XML file
   - ...

Any reaction?

Best regards,

Paul G. Crismer

Some effort went into thinking about these issues a while back, with the
formation of a 'New Eiffel Technology Community' (nETC) and a workshop
at the TOOLS 2011. See
http://netc.se.inf.ethz.ch/bin/view/Main/InitialAnalysis for the initial
analysis (this wiki appears to have been hacked, you may need to look at
the attachments to see the proper diagrams). The workshop presentations
are here - http://netc.se.inf.ethz.ch/bin/view/Main/WorkshopWriteUp

The nETC concept is (slowly) getting going, and there will hopefully be
a meeting at TOOLS 2012 (informal this time - potentially on the 3th,
the day after the Eiffel design feast workshop). We will soon have a
functional web-presence which will hopefully provide a place for people
to not just discuss the problem, but actually do something about it!

- thomas beale

On 18/04/2012 14:21, LARRY RIX wrote:
> Simple basis: The money is NOT in the language or IDE, but in code frameworks
based on the language and IDE, which are for sale. So, the money is made there.
Eiffel already comes with an extensive library "stack", but at a relatively low
level. What is truly virgin territory for Eiffel is a business library and a
developer framework with standard means of moving data between a database and
model or business tier objects and interaction with GUI elements -- with an eye
on controlling state management and so forth. Moreover, as we are using Eiffel
for a very extensive commercial application, I am learning that it is very easy
in Eiffel to get too detailed and too complex too quickly. Any framework needs
to be onion-skinned where a developer has clear choices of complexity in these
internal moving parts of a framework for moving data around a system.
> Bottom line is this: I agree. The language and IDE need to be free and the
framework provided in various levels of cost, from the simple to the complex and
from general to comprehensive -- offering many developers various tools scalable
to their specific client needs. Also, bring web development into full play,
where all of the nice aspects of Eiffel live easily and elegantly in that
environment (e.g. Design by Contract, Multiple Inheritance, Generics, Agents,
SCOOP, etc.). Doing this would go a long way to having Eiffel penetrate the
markets through the developers. Developers get excited about such things and
excitement is what is needed most of all. Get the developer community something
that meets the following criteria and you have a winner:
> Recipe for a Viral Programming Language:
> Congruency with lifestyleThe language semantics, presentation, use (e.g. IDE)
and other aspects must be either easily understood or understanding of these
things must be easily attained.The language and method must dovetail well with
little effort to the real-world needs of creating well crafted software.Strong
emotional appeal.The emotional appeal will be based on ease of use and Rapid
Application Development (how quickly and easily can I deliver to my client?)Wide
audience based on #1 and #2.How many millions of developers are there in the
world?Language presents something extremely surprising.What is seen in either
the language or the method (IDE) must be extremely surprising (e.g. something
completely unpredictable and unexpected by the developer -- not the
same-ole-same-ole-stuff)Developer is able to imagine themselves doing what they
see.Self-explanatory?The price must be right (free or nearly so).
> To: eiffel_software@yahoogroups.com
> From: sboyls@...
> Date: Wed, 18 Apr 2012 07:55:08 -0500
> Subject: Re: [eiffel_software] Javel
> *
>
> *
>
>
>


[Non-text portions of this message have been removed]

Hi,I agree with Paul,  some time ago I published my idea to create an How to
guide, that shows how to do everyday programming tasks in Eiffel, the code
should be hosted in Git, and maybe have the possibility to run the examples
directly in the Browser. The following list show my initial ideas.

1. New to Eiffel (something like Ian Joyner tutorial updated with the last
additions)
2. Eiffel from the command Line
3. How to work with Files?
4. How to Parse JSON?
5. How to Write JSON?
6. How to parse XML?
7. How to write XML?
8. Working with Databases
	 8.1 Oracle
	 8.2 PostgreSQL
	 8.3 SQLite
	 8.4 NoSQL
9. Eiffel and the Web
	 9.1 EWF framework
	 9.2 Writing conventional WebSites
	 9.3 *-RPC def *=JSON, XML
	 9.4. REST services
	 9.5 SOAP?
10. Concurrency Programming in Eiffel
	 10.1 Eiffel SCOOP
	 10.2 Eiffel Threads
11. Eifffel Persistence
12. Testing with Eiffel
13. How to talk with other Languages
	 13.1 Eiffel and C, real world examples, step by step
	 13.2 Eiffel and C++, real world examples, step by step
	 13.3 Eiffel and Java
	 13.3 Eiffel and Python
14. Build and Deploy and Distribution
	 14.1 Eiffel and Jenkins
15. Eiffel Research projects, Future

--- In eiffel_software@yahoogroups.com, "pgcrism" <paul-georges.crismer@...>
wrote:
>
> Hello,
>
> I'am astonished by the vitality of the discussion about "Javel".
> Never thought syntax was of any attracting/repulsing relevance.
> The syntactic diversity of new 'sexy' languages, enforces my opinion.
>
> In my eyes, providing other skins to Eiffel is "nice-to-have".
>
> More attractive to developers is what Larry Lix spoke about in his post
(http://tech.groups.yahoo.com/group/eiffel_software/message/19183.
> 1- frameworks, from the simple to the complex and from general to
comprehensive
> 2- address real-world needs of creating well crafted software
> 3- ease of use and Rapid Application Development (how quickly and easily can I
deliver to my client?)
> 4- advertise the "Eiffel advantage" : Void-safety, DBC, Agents, SCOOP...
>
> #1 and #2 should give testimony that Eiffel is not a "university" or research
language.
>
> #2 and #3 would give some assurance to developers (provide applications to
clients) and to managers (it's worth the money).
>
> I would also add some other topics like:
> - review and enhance the user experience of EiffelStudio
> - make documentation sexier and available (I know people who think Eiffel is a
nearly died language because there apparently is no documentation, and the
community -i.e. chances to get help- is so tiny)
> - publish tutorials about nowadays real world needs (the dining philosophers
is  of no immediate interest) for dummies :
>   - retrieving data from a database
>   - developing a first webservice
>   - reading an XML file
>   - ...
>
> Any reaction?
>
> Best regards,
>
> Paul G. Crismer
>

Hi Paul,

the Javel idea is primarily aimed at bringing (potentially large numbers
of) new users to Eiffel, not making existing users happier.

- thomas

On 19/04/2012 14:37, pgcrism wrote:
>
> Hello,
>
> I'am astonished by the vitality of the discussion about "Javel".
> Never thought syntax was of any attracting/repulsing relevance.
> The syntactic diversity of new 'sexy' languages, enforces my opinion.
>
> In my eyes, providing other skins to Eiffel is "nice-to-have".
>
> More attractive to developers is what Larry Lix spoke about in his
> post (http://tech.groups.yahoo.com/group/eiffel_software/message/19183.
> 1- frameworks, from the simple to the complex and from general to
> comprehensive
> 2- address real-world needs of creating well crafted software
> 3- ease of use and Rapid Application Development (how quickly and
> easily can I deliver to my client?)
> 4- advertise the "Eiffel advantage" : Void-safety, DBC, Agents, SCOOP...
>
> #1 and #2 should give testimony that Eiffel is not a "university" or
> research language.
>
> #2 and #3 would give some assurance to developers (provide
> applications to clients) and to managers (it's worth the money).
>
> I would also add some other topics like:
> - review and enhance the user experience of EiffelStudio
> - make documentation sexier and available (I know people who think
> Eiffel is a nearly died language because there apparently is no
> documentation, and the community -i.e. chances to get help- is so tiny)
> - publish tutorials about nowadays real world needs (the dining
> philosophers is of no immediate interest) for dummies :
> - retrieving data from a database
> - developing a first webservice
> - reading an XML file
> - ...*
> *
>


[Non-text portions of this message have been removed]

Hi,

Having been silent (but silently weeping over bracket curly syntax
suggestions for Eiffel) I must say I agree with Paul G. Crismer. I
think that syntax aesthetics is of minor importance in making Eiffel
more widespread.

On Thu, Apr 19, 2012 at 4:02 PM, javier <vrhj2000@...> wrote:
>
> 1. New to Eiffel (something like Ian Joyner tutorial updated with the last
additions)
> 2. Eiffel from the command Line
> 3. How to work with Files?
> 4. How to Parse JSON?
> 5. How to Write JSON?
> 6. How to parse XML?
> 7. How to write XML?
> 8. Working with Databases
> 8.1 Oracle
> 8.2 PostgreSQL
> 8.3 SQLite
> 8.4 NoSQL
> 9. Eiffel and the Web
> 9.1 EWF framework
> 9.2 Writing conventional WebSites
> 9.3 *-RPC def *=JSON, XML
> 9.4. REST services
> 9.5 SOAP?
> 10. Concurrency Programming in Eiffel
> 10.1 Eiffel SCOOP
> 10.2 Eiffel Threads
> 11. Eifffel Persistence
> 12. Testing with Eiffel
> 13. How to talk with other Languages
> 13.1 Eiffel and C, real world examples, step by step
> 13.2 Eiffel and C++, real world examples, step by step
> 13.3 Eiffel and Java
> 13.3 Eiffel and Python
> 14. Build and Deploy and Distribution
> 14.1 Eiffel and Jenkins
> 15. Eiffel Research projects, Future

I think that adressing and providing solutions to most of these issues
is of huge importance if Eiffel is to become more widespread. Since
Javier started a wish list I would like to add two language features:

16. Syntax: Support for manifest HASH_TABLE expressions. Actually I'd
like to be able to write manifest JSON expressions in Eiffel! That's
where we shoud use curly brackets! ;-)

17. Syntax and core classes: Cleaner and distinct handling of Unicode
characters/strings and octet-sequences.

/Paul

--
Paul Cohen
www.seibostudios.se
mobile: +46 730 787 035
e-mail: paul.cohen@...

On 19/04/2012 15:43, Paul Cohen wrote:
>
> Hi,
>
> Having been silent (but silently weeping over bracket curly syntax
> suggestions for Eiffel) I must say I agree with Paul G. Crismer. I
> think that syntax aesthetics is of minor importance in making Eiffel
> more widespread.
> *
> *
>

that's what I would have said some years ago, but we have a community
with about 1,000 members on it, and Eiffel syntax appears to be a real
mental block for most of them.  In any case, I think we can look at this
particular question relatively quickly, as a background activity. If we
manage to specify it, and it appears to be implementable, then the
actual 'work' of doing it would have to be prioritised by the relevant
tool owners.

- thomas



[Non-text portions of this message have been removed]

*
* If I have in

class GUI_HT_CONTROL

      set_up_agents (...; an_add_item_agent: like add_item_agent; ...)
              -- do then when enabling editing
          do
              ...
              add_item_agent := an_add_item_agent
              ...
          end

      add_item_agent: PROCEDURE [ANY, TUPLE [a_key: STRING; a_value: STRING]]
              -- an agent that can be used to add a new entry to the hash
table

...
end

The above agent would be supplied closed on its target, but with open
arguments. I want to be able to call an undo-redo action manager with a
curried version of the agent with the arguments closed. As far as I can
tell, to do this I have to create a new agent by doing

closed_add_item_agt: like add_item_agent
create closed_add_item_agt.adapt (add_item_agent)
closed_add_item_agt.set_operands ([...])
x.f (closed_add_item_agt) -- pass it somewhere

x.f is declared as PROCEDURE [ANY, TUPLE]

OR I can use wrapping:

closed_add_item_agt (a_key: STRING; a_value: STRING)
      do
          add_item_agent .call ([a_key, a-value])
      end

and use the call:

x.f (agent closed_add_item_agt (a_key, a_value))


Neither of these seems entirely satisfactory - it feels like there
should be an easier way of manufacturing a new agent from an existing
one, with more /all arguments closed.

Am I missing something here?

- thomas



[Non-text portions of this message have been removed]

Hi all,

I have some sympathy with the Javel proposal; not a lot, but some.

Provided that it is possible [as previously commented] to write code in
a selected 'skin', that could be useful, but not a priority.

As Larry Rix noted, a much more important priority is to for a newcomer
to Eiffel, or a newcomer to using Eiffel for a particular purpose to be
demonstrably productive in short order.

I have recently [a latecomer to the scene !] started out on the process
of developing a new website and have been looking for Eiffel
inspiration, especially in using template processing.

There is a stark contrast between the ease of installing and starting to
use PHP [and I have read today's LWN link to PHP's many and severe
deficiencies ...!], or the excellent documentation for the Java based
FreeMarker system of webpage delivery, Eiffel's state of play.

Low cost, in time and effort, in getting started with Eiffel is what is
needed, together with better visibility of Eiffel in use for some widely
used project(s).


There is a lot of Eiffel code that addresses my web server needs, but
essentially no simple, obvious and functional examples to start from.

I am having difficulty seeing the wood for the trees ...

Regards,

Howard

PS Attending TOOLS 2012 and Wednesday's Eiffel workshop.


--
Howard Thomson <howard.thomson@...>

Hi Thomas,

Could you clarify on what community you are talking about. I would hope that
most people reading this list, in this community, are quite happy with Eiffel
syntax and in fact prefer it.

Ian

On 20 Apr 2012, at 00:53, Thomas Beale wrote:

> On 19/04/2012 15:43, Paul Cohen wrote:
>>
>> Hi,
>>
>> Having been silent (but silently weeping over bracket curly syntax
>> suggestions for Eiffel) I must say I agree with Paul G. Crismer. I
>> think that syntax aesthetics is of minor importance in making Eiffel
>> more widespread.
>> *
>> *
>>
>
> that's what I would have said some years ago, but we have a community
> with about 1,000 members on it, and Eiffel syntax appears to be a real
> mental block for most of them.  In any case, I think we can look at this
> particular question relatively quickly, as a background activity. If we
> manage to specify it, and it appears to be implementable, then the
> actual 'work' of doing it would have to be prioritised by the relevant
> tool owners.
>
> - thomas
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Ian Joyner wrote:

> Could you clarify on what community you are talking about. I would hope that
most people reading this list, in this community, are quite happy with Eiffel
syntax and in fact prefer it.
>
> On 20 Apr 2012, at 00:53, Thomas Beale wrote:
>
>> ... we have a community
>> with about 1,000 members on it, and Eiffel syntax appears to be a real
>> mental block for most of them.


Thomas is talking about the openEHR community (www.openehr.org). Thomas has
written a lot of code in Eiffel for openEHR, which he shows to people
frequently. He gets a _lot_ of feedback and, although all of us wish it were
otherwise, the sad fact is that Eiffel's syntactic heritage is a block for most
programmers.

- Peter Gummer

On 20 Apr 2012, at 05:28, Howard Thomson wrote:

> Hi all,
>
> I have some sympathy with the Javel proposal; not a lot, but some.

I think a lot of people would agree, even the proposers.
Perhaps we just need some people on the C-side of the fence to get the vision
independently and come up with C+-, (or C-+) with C++ syntax but Eiffel
semantics. If C people think this comes from the Eiffel people, maybe it is
doomed to failure. We need to somehow appeal to the mob, but we are not in the
mob.

> Provided that it is possible [as previously commented] to write code in
> a selected 'skin', that could be useful, but not a priority.
>
> As Larry Rix noted, a much more important priority is to for a newcomer
> to Eiffel, or a newcomer to using Eiffel for a particular purpose to be
> demonstrably productive in short order.

This seems to be a common complaint in any minority but superior technology. The
WebObjects people complain about the 'learning cliff'. Although now WO is in
Eclipse and with the main library being project wonder, there is a lot of truth
in the learning cliff. I don't think Eiffel has a learning cliff, or even a
particularly steep curve.

There is only one sure way to get newcomers to embark on the learning curve -
give them a paying job where they have to learn the language. Lots of people are
learning Ruby because of RoR and Python because of Django and Pylons. There is
just a lack of Eiffel jobs around.

Can we establish a ground swell to get more Eiffel jobs? Thomas has certainly
been the person most engaged in this part of the world in doing that, and I
admire his ability to be able to stick to it.

It's nice to see people still referring to the tutorial I wrote at least 10
years ago. Is it still that relevant? Thanks Javier, but I agree an addendum
would be good on the latest tuple, agent, and SCOOP stuff. But I don't think I
am the one to do it.

> I have recently [a latecomer to the scene !] started out on the process
> of developing a new website and have been looking for Eiffel
> inspiration, especially in using template processing.
>
> There is a stark contrast between the ease of installing and starting to
> use PHP [and I have read today's LWN link to PHP's many and severe
> deficiencies ...!], or the excellent documentation for the Java based
> FreeMarker system of webpage delivery, Eiffel's state of play.

I was going to ask for a link to that, but I think I have found it at:

http://lwn.net/Articles/492714/

Thanks, I'll have a read. Doug Crockford claims not only PHP, but all similar
technologies of ASP, etc are a disaster (as far as security anyway).
>
> Low cost, in time and effort, in getting started with Eiffel is what is
> needed, together with better visibility of Eiffel in use for some widely
> used project(s).

I have always thought around six months effort is what is needed to learn any
programming system. Part of that length of time is based around the traps and
pitfalls of most languages and systems.

Eiffel carefully avoids all the known traps and pitfalls, so the time should be
shorter.

For example using a class feature name as an argument name or local name, thus
hiding the outer feature.... Gone! No trap to learn here. The careful design of
Eiffel will not only save time in learning it, but save heaps of time in
debugging things later. All around I think Eiffel is a great time saver.

I'm not disagreeing with you, just trying to point out where the effort of
'making it easier' for newcomers is needed.

> There is a lot of Eiffel code that addresses my web server needs, but
> essentially no simple, obvious and functional examples to start from.

So I think we are probably in furious agreement (I hope none thinks we are in
agreeance – where did that horror come from ;-))

Ian

>
> I am having difficulty seeing the wood for the trees ...
>
> Regards,
>
> Howard
>
> PS Attending TOOLS 2012 and Wednesday's Eiffel workshop.
>
>
> --
> Howard Thomson <howard.thomson@...>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Another thought comes out of the wanting to make Eiffel easy for people to
learn. One of the problems, at least with Eiffel Soft (ISE), is one must not
only learn the language, but the whole system. Yes integration is a great thing
for the advanced programmer, but it asks the newcomer to step out of their
context.

One thing I tried to do with MacEiffel was to integrate Eiffel with Apple's
Xcode. Thus programmers only needed to learn the language, not a development
environment, or even the Cocoa libraries – I provided an interface to that.

We hit a few problems though. Apple are and were not in the business of
programming languages. They are totally focussed on their product and making
things simple for the end user. (See Lashinky 'Inside Apple') So they were never
interested. I think Annie had some talks with Apple as well. But they are
completely focussed on Objective-C (the only reasonable version of C).

Secondly, Apple kept changing Xcode too fast. I could not keep up.

Thirdly, I did the interface to Cocoa a stupid way, which needed to some extent
hand-developed interfaces. I should have used the dynamic facilities of the
Obj-C runtime and ignored the performance penalty. (Scripting languages ignore
performance penalties big time.)

Fourthly, I need a paying job as well!

I think there is something to be said though for making the language available
in familiar environments. Xcode, Eclipse, NetBeans?, etc. People generally love
or hate their development environments and if they hate yours, they are not
going to use your language.

I even did Eiffel macros for TextMate (an editor preferred by many programmers
on Mac). My Eiffel macros were far neater and logical than any other macros for
other languages.

Let's also consider Python (ruby, perl) – just download and start it up in
command line and away you go. I know you could run Eiffel from the command line
as well.

Then with Python, you have a very basic IDE, Idle. After that you can use PyDev
for Eclipse.

All these facilities mean that newcomers can slip easily into these other
languages. With Eiffel you are faced with the all-or-nothing learning cliff (ah
so there is a learning cliff after all).

Ian

OK, thanks I thought that was the context. I remember discussing this problem
with Thomas a long time ago.

It's a very sad fact that programmers who have been taught since the demise of
Pascal seem to have a block with ALGOL-heritage syntax. The machine
code/FORTRAN/C people really did a good hatchet job on most of ALGOL heritage,
except for a small concession to structured syntax.

Maybe there has just been too much innovation in the ALGOL line, whereas C has
just stuck with a very mediocre innovation in C++.

I would guess that in EHR there is no emphasis on learning Eiffel. Perhaps
Thomas just expects them to 'get it', but we'd have to check with him.

I can relate to their reluctance. When I first read OOSC (first ed) in 1988, I
was not in the mood to learn another syntax. I just wanted to apply better OO
principles to my then language of choice - Object Pascal. I was about six
chapters in before I got over the 'will I bother to read another chapter'
factor, and realized that it was great stuff.

So I think maybe some training sessions in the EHR community would be needed.
However, I don't know if that would be practical because there might just be
resistance.

So I think the last number of posts have come down to how to educate people in
Eiffel.

Perhaps Thomas has the stealth approach to that by at least exposing them to the
semantics in familiar syntax.

It is also a sad fact that most computer people are tasteless, a fact that Steve
Jobs noted about Microsoft. In this industry there is too much of the
crypticness of mathematics without the clarity of mathematics. We write code
instead of program specifications. Programmers expect to see code instead of
program specifications (which happen to be executable, just as much as and
probably more efficiently than their code).

Ian

On 20 Apr 2012, at 11:43, Peter Gummer wrote:

> Ian Joyner wrote:
>
>> Could you clarify on what community you are talking about. I would hope that
most people reading this list, in this community, are quite happy with Eiffel
syntax and in fact prefer it.
>>
>> On 20 Apr 2012, at 00:53, Thomas Beale wrote:
>>
>>> ... we have a community
>>> with about 1,000 members on it, and Eiffel syntax appears to be a real
>>> mental block for most of them.
>
>
> Thomas is talking about the openEHR community (www.openehr.org). Thomas has
written a lot of code in Eiffel for openEHR, which he shows to people
frequently. He gets a _lot_ of feedback and, although all of us wish it were
otherwise, the sad fact is that Eiffel's syntactic heritage is a block for most
programmers.
>
> - Peter Gummer
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

I have been thinking about this discussion for several days and I have
decided to ask this very simple question. Maybe I'm missing the point
and my ignorance will shine bright for all to see but this is my question.
Why are so worried about changing the language and the look and feel
with special skins? I learned my first programming language in 1984.
The language was Fortran. After that I learned Pascal. I then learned Eiffel
in college. Along the way I learned PL/1, C, C++, Java, and some others.
If I wanted to use a new language I learned the syntax of the language.
I never heard any c programmers wanting to change Java to look more like C.
I never heard and java programmers wanting to make Java look more like C++.

Why can't people learn Eiffel? Why must we call it Javel? It's like saying I
want English to look and sound more like German so more people from Germany will
want to learn something called Germish.

Most programming languages are set of syntax, controls, reserved words, and
libraries so you can write a program to do something. There is no method or
road map to provide a better way to write the program. Eiffel on the other hand
is a method that contains the syntax and key words to support the method.

Good software development principles take time to learn and develop. It takes
time to get comfortable with the concepts and understand how and when to
implement
them. EiffelStudio provides all the tools you need to implement the Eiffel
method.

If I want to learn to speak and write in Russian then I have to learn it whether
I like it or not. It's all part of learning. There is no easy way to do it.

Software Engineering is a technical engineering endever. There can be no
shortcuts in good engineering.

There reasons that existed when Eiffel was first developed and caused it to
take the form it did are probably still the same today. Nothing has changed
so way change the language?

Steve

--- In eiffel_software@yahoogroups.com, Ian Joyner <i.joyner@...> wrote:
>
> Another thought comes out of the wanting to make Eiffel easy for people to
learn. One of the problems, at least with Eiffel Soft (ISE), is one must not
only learn the language, but the whole system. Yes integration is a great thing
for the advanced programmer, but it asks the newcomer to step out of their
context.
>
> One thing I tried to do with MacEiffel was to integrate Eiffel with Apple's
Xcode. Thus programmers only needed to learn the language, not a development
environment, or even the Cocoa libraries – I provided an interface to that.
>
> We hit a few problems though. Apple are and were not in the business of
programming languages. They are totally focussed on their product and making
things simple for the end user. (See Lashinky 'Inside Apple') So they were never
interested. I think Annie had some talks with Apple as well. But they are
completely focussed on Objective-C (the only reasonable version of C).
>
> Secondly, Apple kept changing Xcode too fast. I could not keep up.
>
> Thirdly, I did the interface to Cocoa a stupid way, which needed to some
extent hand-developed interfaces. I should have used the dynamic facilities of
the Obj-C runtime and ignored the performance penalty. (Scripting languages
ignore performance penalties big time.)
>
> Fourthly, I need a paying job as well!
>
> I think there is something to be said though for making the language available
in familiar environments. Xcode, Eclipse, NetBeans?, etc. People generally love
or hate their development environments and if they hate yours, they are not
going to use your language.
>
> I even did Eiffel macros for TextMate (an editor preferred by many programmers
on Mac). My Eiffel macros were far neater and logical than any other macros for
other languages.
>
> Let's also consider Python (ruby, perl) – just download and start it up in
command line and away you go. I know you could run Eiffel from the command line
as well.
>
> Then with Python, you have a very basic IDE, Idle. After that you can use
PyDev for Eclipse.
>
> All these facilities mean that newcomers can slip easily into these other
languages. With Eiffel you are faced with the all-or-nothing learning cliff (ah
so there is a learning cliff after all).
>
> Ian
>

Tom,

Usually as you know I just lurk here. Long time no talk. Back in Oz - on the
Sunshine Coast - lots of stuff happening, but very little in the Eiffel sphere.

This last topic is the first to drag me out of lurking for ages (a year?).
My two cents worth though is that it's not a good direction to head.

Generally, even if implemented such suggestions will not improve the appeal of
Eiffel as a language - or draw interest and understanding from those who already
find reading Eiffel difficult. (opinion - of course)

The use of '<keyword>' 'end' pairs is much superior to curly braces - although
still not the best solution, changing to curly braces would be retrograde IMHO.
Curly braces are 'noisy' and somewhat ambiguous - although the latter point can
be applied to 'end' as well. They may be familiar but they are mostly ignored by
human readers.

Introducing backwards declarations is the most horrible decision of the three -
again just opinion. Well named classes and well named entities should never
create confusion regardless or order - one being specific and one being general
(e.g. HORSE wilbur - and wilbur Horse, or even a_horse HORSE etc). No natural
language (that I know of) has a grammar that is backwards - but tellingly
English is the de-facto common language of programmers - and all romance
languages in general are nominative-accusative in grammar. Korean and Japanese
programmers use English languages programming languages - and their native
languages is still "wilbur horse (is)", verb trailing or implied as trailing.

CamelCase is of course a de-facto standard. Upper case style isn't technically
enforced by Eiffel compilers (although, as an aside - it should be in my
opinion). Then again, CamelCase isn't enforced by other languages and tools
(although again, it should be).

On this last point, I believe that style should be just that - a visual
representation. Underlying that, my ideal compiler would treat 'LARGE_HIPPO" and
"LargeHippo" as exactly the same identifier. That is, I would ignore case (not
all languages are bicameral) and formatting within the identifier (use of
underscores and spaces) and just read the identifier. i.e. "_LARGE__HIPPO" is
also the same. However, an identifier should always be written exactly the way
it is first declared - so that the use of "LargeHippo" and "LARGE_HIPPO" in the
same compilation unit is an error. (Especially not "LaRgEHiPpO" !)

And, of course style should be enforced - although this could be a compiler
setting to satisfy the weak-minded (don't repeat that).

Generally though, I think that overall leaving things the way the are is better.
I don't think there are any real gains to be got.

Anyway,
Good Luck in Prague. I'd like to see Prague, but I'm too committed elsewhere to
make it this year and the selected topics aren't of sufficient interest to me to
change things up.

Peter Lubke


--- On Thu, 19/4/12, Thomas Beale <Thomas.Beale@...> wrote:

From: Thomas Beale <Thomas.Beale@...>
Subject: [eiffel_software] Javel page
To: "eiffel_software@yahoogroups.com" <eiffel_software@yahoogroups.com>
Received: Thursday, 19 April, 2012, 11:03 PM
















 











All,



for those interested in a concrete proposal leading to an

implementation, please see this page I have set up -

http://dev.eiffel.com/Eiffel_Language_Skins . I am happy to try to act

as a facilitator for this activity, and accordingly I created a rough

framework for considering the problem. My suggestions for proceeding are

as follows:



* if you want to actually contribute, please use the page above and

     its discussion page(s) to do this, and set a 'watch' on the main page

       o if you violently disagree with the way I have set out the

         problem on this page, please feel free to say so on the

         discussion page, and we can discuss alternatives

       o if you have a personal proposal that you particularly want to

         post as a reference, please follow the instructions in the page

         to do with creating a new page for your ideas and setting a link

         to it (I know many people have thought about ideas around this

         subject in the past)

       o otherwise, we will use the discussion pages to crystallise out

         directly a set of rules and implementation ideas for Javel.

   * it you just want to follow, set a 'watch' on the main page



Please note that I have not had time to go through all the voluminous

posts here on this list, so if your great ideas are not yet on the page,

please put them there or link to your posts etc.



On the name Javel: we have not decided on any final name, but this

suggestion from Bertrand is easy to pronounce, and I think we should use

it as a working name for now.



Last note: this is not intended as an open-ended theoretical or academic

exercise. We are really looking at if & how a friendly (to C-syntax

lovers) skin could be put on tools like EiffelStudio and any other

compiler, that would enable those people to use Eiffel but see it

through a syntax they understand. Consequently I have defined an initial

timeline!



- thomas beale



[Non-text portions of this message have been removed]



























[Non-text portions of this message have been removed]

> So i dare to propose a new nCAP (nearly-Certified Attachment Pattern) :
>
> AIM: ease the transition to void-safety
> PROPOSAL:
> - a query whose result is guaranteed "not void" by a postcondition is
> considered as "attached" to clients.
> - A warning is issued to encourage migration of non-void-safe providers.

I think this is doable. We already have a CAP based on postconditions which are
always False, like {EXCEPTIONS}.die. This is used by the compiler to know that
when you call this routine, this is going to fail anyway.

This is unlikely to be added to 7.1 as we are wrapping up the development for
the
release next month but we will see how we can integrate that to 7.2.

Regards,
Manu

Hi Peter,

Have not heard from you from a long time. I find myself agreeing with most
things people say here, one way or the other. I agree with Thomas that people
from C background have problems with anything that is not C syntax and I think
for no good reason. Learning programming language syntax is nothing like
learning a new natural language, but learning the semantics (and that includes
all the traps which you have in C, but a lack of in Eiffel) is a different
issue. So I found myself torn between, OK, let's cater to the prejudice and
stupidity to let's not.

It has always been a problem that more difficult and arcane things become
established and those who bother to learn them (maybe because they have to), are
very difficult to show something else. IBM people couldn't see the amazing
capabilities of Burroughs systems with high-level languages (all very close to
ALGOL), virtual memory, out-of-bounds checks, easy operations, etc. No they
preferred arcaneness. Same with with MS-DOS vs Mac, then Windows being arcane.
Computing people just lack taste.

Maybe Thomas's idea is just to try changing them one stage at a time. I also
posted today that we should make Eiffel work in more IDEs. Those of choice of
many programmers who get wedded to Eclipse, etc.

I think you are right that Eiffel's beautiful syntax reflects the understanding
and taste of its originator and the total-world thinking behind Eiffel.

Hmmm, my preliminary remarks seem to again have been so long, that what you
prompted me into thinking is deserving of another post.

So now for a message from our unsponsor.

Ian



On 20 Apr 2012, at 13:26, Peter Lubke wrote:

> Tom,
>
> Usually as you know I just lurk here. Long time no talk. Back in Oz - on the
Sunshine Coast - lots of stuff happening, but very little in the Eiffel sphere.
>
> This last topic is the first to drag me out of lurking for ages (a year?).
> My two cents worth though is that it's not a good direction to head.
>
> Generally, even if implemented such suggestions will not improve the appeal of
Eiffel as a language - or draw interest and understanding from those who already
find reading Eiffel difficult. (opinion - of course)
>
> The use of '<keyword>' 'end' pairs is much superior to curly braces - although
still not the best solution, changing to curly braces would be retrograde IMHO.
Curly braces are 'noisy' and somewhat ambiguous - although the latter point can
be applied to 'end' as well. They may be familiar but they are mostly ignored by
human readers.
>
> Introducing backwards declarations is the most horrible decision of the three
- again just opinion. Well named classes and well named entities should never
create confusion regardless or order - one being specific and one being general
(e.g. HORSE wilbur - and wilbur Horse, or even a_horse HORSE etc). No natural
language (that I know of) has a grammar that is backwards - but tellingly
English is the de-facto common language of programmers - and all romance
languages in general are nominative-accusative in grammar. Korean and Japanese
programmers use English languages programming languages - and their native
languages is still "wilbur horse (is)", verb trailing or implied as trailing.
>
> CamelCase is of course a de-facto standard. Upper case style isn't technically
enforced by Eiffel compilers (although, as an aside - it should be in my
opinion). Then again, CamelCase isn't enforced by other languages and tools
(although again, it should be).
>
> On this last point, I believe that style should be just that - a visual
representation. Underlying that, my ideal compiler would treat 'LARGE_HIPPO" and
"LargeHippo" as exactly the same identifier. That is, I would ignore case (not
all languages are bicameral) and formatting within the identifier (use of
underscores and spaces) and just read the identifier. i.e. "_LARGE__HIPPO" is
also the same. However, an identifier should always be written exactly the way
it is first declared - so that the use of "LargeHippo" and "LARGE_HIPPO" in the
same compilation unit is an error. (Especially not "LaRgEHiPpO" !)
>
> And, of course style should be enforced - although this could be a compiler
setting to satisfy the weak-minded (don't repeat that).
>
> Generally though, I think that overall leaving things the way the are is
better. I don't think there are any real gains to be got.
>
> Anyway,
> Good Luck in Prague. I'd like to see Prague, but I'm too committed elsewhere
to make it this year and the selected topics aren't of sufficient interest to me
to change things up.
>
> Peter Lubke
>
>
> --- On Thu, 19/4/12, Thomas Beale <Thomas.Beale@...> wrote:
>
> From: Thomas Beale <Thomas.Beale@...>
> Subject: [eiffel_software] Javel page
> To: "eiffel_software@yahoogroups.com" <eiffel_software@yahoogroups.com>
> Received: Thursday, 19 April, 2012, 11:03 PM
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> All,
>
>
>
> for those interested in a concrete proposal leading to an
>
> implementation, please see this page I have set up -
>
> http://dev.eiffel.com/Eiffel_Language_Skins . I am happy to try to act
>
> as a facilitator for this activity, and accordingly I created a rough
>
> framework for considering the problem. My suggestions for proceeding are
>
> as follows:
>
>
>
> * if you want to actually contribute, please use the page above and
>
>    its discussion page(s) to do this, and set a 'watch' on the main page
>
>      o if you violently disagree with the way I have set out the
>
>        problem on this page, please feel free to say so on the
>
>        discussion page, and we can discuss alternatives
>
>      o if you have a personal proposal that you particularly want to
>
>        post as a reference, please follow the instructions in the page
>
>        to do with creating a new page for your ideas and setting a link
>
>        to it (I know many people have thought about ideas around this
>
>        subject in the past)
>
>      o otherwise, we will use the discussion pages to crystallise out
>
>        directly a set of rules and implementation ideas for Javel.
>
>  * it you just want to follow, set a 'watch' on the main page
>
>
>
> Please note that I have not had time to go through all the voluminous
>
> posts here on this list, so if your great ideas are not yet on the page,
>
> please put them there or link to your posts etc.
>
>
>
> On the name Javel: we have not decided on any final name, but this
>
> suggestion from Bertrand is easy to pronounce, and I think we should use
>
> it as a working name for now.
>
>
>
> Last note: this is not intended as an open-ended theoretical or academic
>
> exercise. We are really looking at if & how a friendly (to C-syntax
>
> lovers) skin could be put on tools like EiffelStudio and any other
>
> compiler, that would enable those people to use Eiffel but see it
>
> through a syntax they understand. Consequently I have defined an initial
>
> timeline!
>
>
>
> - thomas beale
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

openEHR I would guess is quite representative of the developers of any
domain vertical - most won't look at Eiffel syntax, or indeed languages
outside the mainstream ones (but note this includes PHP, Python and
Ruby, where the ease-of-use trumps any concern with syntax).

In the end, it will never work to 'educate' people in Eiffel in a
community like openEHR. They just won't go there. Instead, what could
work is sharing the openEHR models and code of the archetype compiler,
something most people do want (if only to rewrite in their own
language)... in the future I imagine what this would be like with a
version of EiffelStudio that has Javel built in. In fact, a
'JavelStudio' tool. Then I extrapolate to developers in finance (C#,
SQL, Java), telecoms (heavy C++ users), real-time control (C++, Java),
and other industries I have worked in, and I wonder how many new users
we could get, when syntax ceases to be a blocker. (In the meantime, we
need to work on the new Eiffel Technology Community and make some other,
far more substantive changes, as mentioned by Paul Crismer & Paul Cohen).

- thomas

On 20/04/2012 03:21, Ian Joyner wrote:
>
> OK, thanks I thought that was the context. I remember discussing this
> problem with Thomas a long time ago.
>
> It's a very sad fact that programmers who have been taught since the
> demise of Pascal seem to have a block with ALGOL-heritage syntax. The
> machine code/FORTRAN/C people really did a good hatchet job on most of
> ALGOL heritage, except for a small concession to structured syntax.
>
> Maybe there has just been too much innovation in the ALGOL line,
> whereas C has just stuck with a very mediocre innovation in C++.
>
> I would guess that in EHR there is no emphasis on learning Eiffel.
> Perhaps Thomas just expects them to 'get it', but we'd have to check
> with him.
>
> I can relate to their reluctance. When I first read OOSC (first ed) in
> 1988, I was not in the mood to learn another syntax. I just wanted to
> apply better OO principles to my then language of choice - Object
> Pascal. I was about six chapters in before I got over the 'will I
> bother to read another chapter' factor, and realized that it was great
> stuff.
>
> So I think maybe some training sessions in the EHR community would be
> needed. However, I don't know if that would be practical because there
> might just be resistance.
>
> So I think the last number of posts have come down to how to educate
> people in Eiffel.
>
> Perhaps Thomas has the stealth approach to that by at least exposing
> them to the semantics in familiar syntax.
>
> It is also a sad fact that most computer people are tasteless, a fact
> that Steve Jobs noted about Microsoft. In this industry there is too
> much of the crypticness of mathematics without the clarity of
> mathematics. We write code instead of program specifications.
> Programmers expect to see code instead of program specifications
> (which happen to be executable, just as much as and probably more
> efficiently than their code).
> *
> *
>


[Non-text portions of this message have been removed]

Hi Peter,

I would say that this Javel proposal is not about doing something
virtuous, merely something that appears necessary (and on its own
insufficient, of course)... it's not about replacing Eiffel syntax at
all, just about adding other possibilities to break down barriers.

- thomas

On 20/04/2012 04:26, Peter Lubke wrote:
>
> Tom,
>
> Usually as you know I just lurk here. Long time no talk. Back in Oz -
> on the Sunshine Coast - lots of stuff happening, but very little in
> the Eiffel sphere.
>
> This last topic is the first to drag me out of lurking for ages (a year?).
> My two cents worth though is that it's not a good direction to head.
>
> Generally, even if implemented such suggestions will not improve the
> appeal of Eiffel as a language - or draw interest and understanding
> from those who already find reading Eiffel difficult. (opinion - of
> course)
>
> The use of '<keyword>' 'end' pairs is much superior to curly braces -
> although still not the best solution, changing to curly braces would
> be retrograde IMHO. Curly braces are 'noisy' and somewhat ambiguous -
> although the latter point can be applied to 'end' as well. They may be
> familiar but they are mostly ignored by human readers.
>
> Introducing backwards declarations is the most horrible decision of
> the three - again just opinion. Well named classes and well named
> entities should never create confusion regardless or order - one being
> specific and one being general (e.g. HORSE wilbur - and wilbur Horse,
> or even a_horse HORSE etc). No natural language (that I know of) has a
> grammar that is backwards - but tellingly English is the de-facto
> common language of programmers - and all romance languages in general
> are nominative-accusative in grammar. Korean and Japanese programmers
> use English languages programming languages - and their native
> languages is still "wilbur horse (is)", verb trailing or implied as
> trailing.
>
> CamelCase is of course a de-facto standard. Upper case style isn't
> technically enforced by Eiffel compilers (although, as an aside - it
> should be in my opinion). Then again, CamelCase isn't enforced by
> other languages and tools (although again, it should be).
>
> On this last point, I believe that style should be just that - a
> visual representation. Underlying that, my ideal compiler would treat
> 'LARGE_HIPPO" and "LargeHippo" as exactly the same identifier. That
> is, I would ignore case (not all languages are bicameral) and
> formatting within the identifier (use of underscores and spaces) and
> just read the identifier. i.e. "_LARGE__HIPPO" is also the same.
> However, an identifier should always be written exactly the way it is
> first declared - so that the use of "LargeHippo" and "LARGE_HIPPO" in
> the same compilation unit is an error. (Especially not "LaRgEHiPpO" !)
>
> And, of course style should be enforced - although this could be a
> compiler setting to satisfy the weak-minded (don't repeat that).
>
> Generally though, I think that overall leaving things the way the are
> is better. I don't think there are any real gains to be got.
>
> Anyway,
> Good Luck in Prague. I'd like to see Prague, but I'm too committed
> elsewhere to make it this year and the selected topics aren't of
> sufficient interest to me to change things up.*
> *
>


[Non-text portions of this message have been removed]

On 20/04/2012 02:45, Ian Joyner wrote:
> On 20 Apr 2012, at 05:28, Howard Thomson wrote:
>
>> Hi all,
>>
>> I have some sympathy with the Javel proposal; not a lot, but some.
> I think a lot of people would agree, even the proposers.
> Perhaps we just need some people on the C-side of the fence to get the vision
independently and come up with C+-, (or C-+) with C++ syntax but Eiffel
semantics. If C people think this comes from the Eiffel people, maybe it is
doomed to failure. We need to somehow appeal to the mob, but we are not in the
mob.
>
> *
> *

Ian,
that actually may be a very important consideration, which is why, if
this Javel thing manages to get to implementation, I would strongly
recommend branding it and locating it in a different way from Eiffel
entirely. I know it is terrible to have to think like that but we have
to face reality.

- thomas


[Non-text portions of this message have been removed]

OK, welcome back as they say. What Peter prompted me to think was - and I've
sort of said this before is:

Why not ditch more text? Get rid of the argument between 'end' and '}'. What are
these – just separators. What is the usual graphical separator? A solid
horizontal line. You'll find it in newspapers, magazines, as a separator on OS X
menus, etc.

Smalltalk might be right, it tries to be LISP-like and use as little syntax as
possible. If syntax is our problem.... just get rid of it.... ta da!

I never liked class as a keyword anyway. Get rid of it.

Do we need if .. then, maybe:

	 ? <guard> --> (the arrow a graphic, auto generated with no typing).

I think this could all follow Bertrand's comb-like style, with horizontal line
separators actually resembling tooth combs!

Even the comment -- could be the – em-dash like in typography. The reason we
have avoided all these typographic characters is that they used to be difficult
to input. The reason CamelCase came about was that in Smalltalk, the _ was
impossible to input because it wasn't even on the Xerox PARC keyboard.

On the comment character, pressing - twice (or even /) could result in an
em-dash. We could have input methods much as Chinese characters are input by
multiple (and easy) keystrokes to make graphical characters.

We are being too constrained to a textual world by old technology. The
constraints have long been removed. Why are programmers the last to catch up. I
thought we were supposed to be the big innovators. Here we are designing user
interfaces for others, and we can't even produce a modern one for ourselves!

Perhaps there is another root of Thomas's observed problems. Programmers aren't
used to seeing programs presented typographically – for some reason they think
monotype must be more efficient.

Of course, my proposal here is just to develop a new IDE and that contradicts my
suggestion that Eiffel should be available on IDEs like Eclipse. I think there
is a lot of work that could be done, with no guarantee of success, which is why
Thomas is suggesting taking an simple route.

Ian

On 20 Apr 2012, at 13:26, Peter Lubke wrote:

> Tom,
>
> Usually as you know I just lurk here. Long time no talk. Back in Oz - on the
Sunshine Coast - lots of stuff happening, but very little in the Eiffel sphere.
>
> This last topic is the first to drag me out of lurking for ages (a year?).
> My two cents worth though is that it's not a good direction to head.
>
> Generally, even if implemented such suggestions will not improve the appeal of
Eiffel as a language - or draw interest and understanding from those who already
find reading Eiffel difficult. (opinion - of course)
>
> The use of '<keyword>' 'end' pairs is much superior to curly braces - although
still not the best solution, changing to curly braces would be retrograde IMHO.
Curly braces are 'noisy' and somewhat ambiguous - although the latter point can
be applied to 'end' as well. They may be familiar but they are mostly ignored by
human readers.
>
> Introducing backwards declarations is the most horrible decision of the three
- again just opinion. Well named classes and well named entities should never
create confusion regardless or order - one being specific and one being general
(e.g. HORSE wilbur - and wilbur Horse, or even a_horse HORSE etc). No natural
language (that I know of) has a grammar that is backwards - but tellingly
English is the de-facto common language of programmers - and all romance
languages in general are nominative-accusative in grammar. Korean and Japanese
programmers use English languages programming languages - and their native
languages is still "wilbur horse (is)", verb trailing or implied as trailing.
>
> CamelCase is of course a de-facto standard. Upper case style isn't technically
enforced by Eiffel compilers (although, as an aside - it should be in my
opinion). Then again, CamelCase isn't enforced by other languages and tools
(although again, it should be).
>
> On this last point, I believe that style should be just that - a visual
representation. Underlying that, my ideal compiler would treat 'LARGE_HIPPO" and
"LargeHippo" as exactly the same identifier. That is, I would ignore case (not
all languages are bicameral) and formatting within the identifier (use of
underscores and spaces) and just read the identifier. i.e. "_LARGE__HIPPO" is
also the same. However, an identifier should always be written exactly the way
it is first declared - so that the use of "LargeHippo" and "LARGE_HIPPO" in the
same compilation unit is an error. (Especially not "LaRgEHiPpO" !)
>
> And, of course style should be enforced - although this could be a compiler
setting to satisfy the weak-minded (don't repeat that).
>
> Generally though, I think that overall leaving things the way the are is
better. I don't think there are any real gains to be got.
>
> Anyway,
> Good Luck in Prague. I'd like to see Prague, but I'm too committed elsewhere
to make it this year and the selected topics aren't of sufficient interest to me
to change things up.
>
> Peter Lubke
>
>
> --- On Thu, 19/4/12, Thomas Beale <Thomas.Beale@...> wrote:
>
> From: Thomas Beale <Thomas.Beale@...>
> Subject: [eiffel_software] Javel page
> To: "eiffel_software@yahoogroups.com" <eiffel_software@yahoogroups.com>
> Received: Thursday, 19 April, 2012, 11:03 PM
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> All,
>
>
>
> for those interested in a concrete proposal leading to an
>
> implementation, please see this page I have set up -
>
> http://dev.eiffel.com/Eiffel_Language_Skins . I am happy to try to act
>
> as a facilitator for this activity, and accordingly I created a rough
>
> framework for considering the problem. My suggestions for proceeding are
>
> as follows:
>
>
>
> * if you want to actually contribute, please use the page above and
>
>    its discussion page(s) to do this, and set a 'watch' on the main page
>
>      o if you violently disagree with the way I have set out the
>
>        problem on this page, please feel free to say so on the
>
>        discussion page, and we can discuss alternatives
>
>      o if you have a personal proposal that you particularly want to
>
>        post as a reference, please follow the instructions in the page
>
>        to do with creating a new page for your ideas and setting a link
>
>        to it (I know many people have thought about ideas around this
>
>        subject in the past)
>
>      o otherwise, we will use the discussion pages to crystallise out
>
>        directly a set of rules and implementation ideas for Javel.
>
>  * it you just want to follow, set a 'watch' on the main page
>
>
>
> Please note that I have not had time to go through all the voluminous
>
> posts here on this list, so if your great ideas are not yet on the page,
>
> please put them there or link to your posts etc.
>
>
>
> On the name Javel: we have not decided on any final name, but this
>
> suggestion from Bertrand is easy to pronounce, and I think we should use
>
> it as a working name for now.
>
>
>
> Last note: this is not intended as an open-ended theoretical or academic
>
> exercise. We are really looking at if & how a friendly (to C-syntax
>
> lovers) skin could be put on tools like EiffelStudio and any other
>
> compiler, that would enable those people to use Eiffel but see it
>
> through a syntax they understand. Consequently I have defined an initial
>
> timeline!
>
>
>
> - thomas beale
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>