Documentation suggestions

[Bertrand Meyer]

We are looking into improving documentation at http://eiffel.org, as well as supporting material such as YouTube videos, and will be grateful for suggestions. The focus is on very concrete, how-to questions. Here is a typical example. I am an Eiffel novice (although I may have experience in other approaches) and am curious about how to do iterations in Eiffel. I do a Google search for  “iteration in Eiffel” (I – the real “I”this time – think this is the way people typically work these days, they don’t go to eiffel.org and obediently follow the hierarchical structure). I get this:

 

                https://www.eiffel.org/doc/solutions/EiffelBase%2C%20Iteration

 

and go to the first hit:

 

                https://www.eiffel.org/doc/solutions/EiffelBase%2C%20Iteration

 

The information I get there is not wrong but is not what I mostly need:

·         It’s too long. People nowadays are impatient, they want to see the key points first. If they ask a short question they want a short answer first. They don’t want to read a long page, at least not at first. They will read the long explanation if they got the basic idea and need more details, but only then. There should be a summary at the start.

·         It does not start with the most up-to-date information. In fact modern Eiffel has a beautiful iteration mechanism (really beautiful, as I can testify from extensive use in recent weeks), `across’. But the focus of the article is on stuff that was available 15 years ago – still useful but not the default solution.

 

What I (the real “I”) would like to see is more examples of this kind: what kind of simple, concrete information is not as easy to find as it should be. The ideal case in one in your own experience: you were looking for some concrete how-to information (like, above, how-to do iteration in Eiffel) and had trouble finding it.

 

If possible, give a rating for the importance of your request, on a 1 to 10 (higher meaning more important) scale. A low rating is not necessarily a killer --- the criterion for deciding to take up a request is a mix between importance and ease of implementation.

 

I am sure many members of this group have examples of that kind.

 

Thanks in advance!

 

-- Bertrand Meyer

LASER summer school, Elba island,2-10 June, bitcoin/blockchains, https://www.laser-foundation.org/school/ 

 

[Woland's Cat]

Perhaps an easy way to see what this information could look like is to simply put real questions into google, but for languages you can't remember the details of. I have to work in Java, and occasionally PHP, and reasonably often in bash shell. For those, I have to admit, I do type in things like 'java 8 iterators' or 'addition real numbers bash'; the best result is usually a stackoverflow page, on which someone has helpfully laid out the 5 (or whatever it is) ways to do iteration in Java, but concisely, because the writer assumes he/she is talking to another developer, just one who doesn't know java that well.

It may even be that a stackoverflow kind of tool is the right one to use, either the real one, or Atlassian 'Questions', or similar.

Either way, the way these kinds of answers must be written in my view is developer to developer. Developer A knows what OO, curried functions / lambdas, and so on, are; she just wants to know what it looks like in Eiffel. So developer B should answer in that way.

- thomas

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.

--
Thomas Beale
Principal, Ars Semantica
Consultant, ABD Project, Intermountain Healthcare
Management Board, Specifications Program Lead, openEHR Foundation
Chartered IT Professional Fellow, BCS, British Computer Society
Health IT blog | Culture blog | The Objective Stance

[Larry Rix]

Thank you for the excellent feedback!

Your point is well taken and reasonable. I will work towards developing a "Documentation Pattern" so that all of the docs.eiffel.org start following an expected pattern. I think this will also help the crawlers like Google to more easily digest.

Speaking of Google and crawling. I think I ought to also get a basic SEO plan together so that the material generated is not only easily consumed, but is in such a format as to be more easily consumed and catalogued.

QUESTION: Ought we to put Q&A for Eiffel docs directly on to Stackoverflow, Quora, and others with backlinks to docs.eiffel.org? It might not only help strengthen people looking to eiffel.org, but Stackoverflow presence as well.

Larry Rix
Moonshot Software

Rocket science for everyone!

Savannah, GA

770-295-9729

--

You received this message because you are subscribed to the Google Groups "Eiffel Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users+unsubscribe@googlegroups.com.

[john s wolter]

Google has a number of free marketing tools that would be useful in finding indirect Eiffel key-words.  Search has been used in a number of interesting ways.  An example is finding the extent of yearly flu outbreaks.  Search tools using common flu search text help map where and how much viruses were being searched.  Many searches implies a flu outbreak.

Using "Eiffel" variations might give hints some leads on how to key-word pages for search crawlers to index.

Search text frequencies can also suggest subjects for tutorials that need coverage.  It could be that similar issues in C++, C#, and other OOP languages constantly appear & thus can be expected to appear for Eiffel.  There are also various web crawlers that could look at specific subject areas.

This is just a starting suggestion which can have many variations.

Once you gain a broad view of what is on people's minds, you can develop a tutorial & then marketing plans. 

Cheers,
John S. Wolter
------------------------------------------------------------

Wolter Works, LLC
EMail:

​​

johns...@wolterworks.com
LinkedIn: John S Wolter, johnswolter

[Bertrand Meyer]

OK, thanks for the marketing advice. It’s good, but my immediate request is more down-to-earth:  concrete examples of topics for which, as Eiffel users, you have encountered missing, incomplete or inaccurate documentation, which we could fix in the coming weeks.

 

With best regards,

 

-- Bertrand Meyer

LASER summer school, Elba island,2-10 June, bitcoin/blockchains, https://www.laser-foundation.org/school/ 

 

--

You received this message because you are subscribed to the Google Groups "Eiffel Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

[john s wolter]

Marketing is a response to your requests, is down to Earth, and is in the trenches.  Good documentation is good marketing.  It all folds togerther.  

Editing Eiffel documentation requires people in the Eiffel know.  But wait there's more.  The use of marketing tools allow the editors to better understand who is the target audience.  Given that knowledge, it will be easier to shape the documentation.

Cheers,
John S. Wolter
------------------------------------------------------------

Wolter Works, LLC
EMail: johns...@wolterworks.com
LinkedIn: John S Wolter, johnswolter

--

To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Eiffel Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users+unsubscribe@googlegroups.com.

[Ian Joyner]

Marketing is fooling people into doing something that they might not want to do, and is not in their own interests!

But you have a good point in using Google in the best way possible to enhance people’s search results.

Bertrand has a good point that good material needs to be provided in the first place.

Ian

To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

[Larry Rix]

To the Eiffel Community at large—can you please share issues where you needed an answer and the documentation was missing, incorrect, incomplete, or not easily understood?

Larry Rix
Moonshot Software

Rocket science for everyone!

Savannah, GA

770-295-9729

On Wed, May 16, 2018 at 4:57 AM, Bertrand Meyer <Bertran...@inf.ethz.ch> wrote:

To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Eiffel Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users+unsubscribe@googlegroups.com.

[Volkan Arslan]

I would appreciate to have more detailed description (of the different use-cases) of interfacing with the C language.

Also, more detailed descprition of interfacing with .NET would be quite beneficial.

Regards, Volkan.
 

[Larry Rix]

I will put that on the list of suggested needs!

Thanks Volkan!

Larry Rix
Moonshot Software

Rocket science for everyone!

Savannah, GA

770-295-9729

--

[Woland's Cat]

On 16/05/2018 11:56, Larry Rix wrote:

To the Eiffel Community at large—can you please share issues where you needed an answer and the documentation was missing, incorrect, incomplete, or not easily understood?

There are two audiences I would suggest:

• a small number of old-timers like me, whose questions are of the form 'what's the new form of xyz syntax', or even 'what are the exact semantics of the ~ operation, again?', or 'what are the new rules for default attached status?'
• the answers to such questions need to be succinct and with relevant deep links into the reference materials
  
• people new to Eiffel who are perfectly competent in all OO and functional programming, and just want to know how Eiffel does iterators, lambdas etc
• the answers to these questions need to succinct, but in a more discursive way, e.g. perhaps like the style of some of these answers on java 8 iterators.
• actual new developers who need to learn theory and programming at the same time. I'm tempted to say, point them to Bertrand's Touch of Class site (assuming it still exists).

On the last point, I'm a great fan of the TOC material, and I think it would be worth putting deep links into it from eiffel.org material, even that intended for pros.

My own searches are always of the first kind: what are today's rules for .ecf, agent syntax, detached/attached, mixed mode compilation, etc etc.

hope this helps.

- thomas

[Larry Rix]

Hi Thomas,

Have you performed such searches recently that you can point to as example needs?

Larry Rix
Moonshot Software

Rocket science for everyone!

Savannah, GA

770-295-9729

--

[lrix]

Please take a look at the video linked below and provide your feedback.

https://youtu.be/Hqc-xSrKwvc

[lrix]

Also at: https://youtu.be/P0M0Vpxofi4

I have removed the intro and outro graphics, music, and music from the body. All that remains is the instructional part with female voice over audio. There is also captioning.

Per Thomas Beale's suggestion, I have reduced the size of ES and isolated the screen capture to just the ES window. This makes the output larger and loses the distractions of my overall desktop environment.

Note that Annie Meyer also mentioned not liking the intro, outro, and music scores as she considered them too distracting.

[lrix]

All the videos I have created today exist in a playlist found at:

https://www.youtube.com/playlist?list=PLf9JgTngKbj6hd2yI_BQhC_blwvtrpdRh

[john s wolter]

Irix,

My emotional response is that the voice-over is robotic & stale.  Spoken dialog needs a sense of human interaction.  The discussion is swimming in unexplained Jargon.  Glossaries can help for more detail but still even while discussing technical features a narrative style is needed.  

Einstein used thought puzzles to help learners & communicate about Relativity.  The key here is "narrative" styl It creates an emotional recall of material for a Learner mind.  

The screen is visual chaos.  Seeing that entire development tool's presentation, Learners will be distracted.  Prior setting of the stage is needed informing a viewer, the Learner, about the story that is about to be presented.

Khanacademy.org style is a good step forward but more can be done for production in that direction.

Cheers,
John S. Wolter
------------------------------------------------------------

Wolter Works, LLC
EMail: johns...@wolterworks.com
LinkedIn: John S Wolter, johnswolter

--

[john s wolter]

Irix,

Your 1st playlist video is a good start using a chalkboard, different color chalk, with words.  It needs a voice-over to announce the content ahead.  This good start switched to the robotic voice in subsequent videos. 

BTW the hand in the 1st video is unneeded & is distracting.  Just writing the words is what is needed.  The writing needs to be slower.

   

Cheers,
John S. Wolter
------------------------------------------------------------

Wolter Works, LLC
EMail: johns...@wolterworks.com
LinkedIn: John S Wolter, johnswolter

On Wed, May 16, 2018 at 1:33 PM, lrix <lr...@jinny.com> wrote:

All the videos I have created today exist in a playlist found at:

https://www.youtube.com/playlist?list=PLf9JgTngKbj6hd2yI_BQhC_blwvtrpdRh

[Larry Rix]

I understand about the robotic voice. However, while it might be stale, one of the goals is consistency of voice, tone, inflection, and style. Moreover, what is not seen behind the scenes is how much work it requires to produce just one of these 1-2 minute videos. A simple flub while reading (as a person) the "script" means that I have to start all over again. Moreover, if I don't use a script, it is extremely difficult to keep the videos short and on-topic and on-task. If I goof a script 3 times on a two minute video, the resulting time increase is can be 10-15 minutes. So, instead of being able to produce 4-6 of these per hour, I am now down to 2-3 (about 1/2 production rate). That's a big deal to me as the one making the material. :-) BTW—the Text-2-Speech program never gets tired, never goofs, always says things the same way, and always uses the same cadence of speech. It might be robotic and stale, but it's dependable and consistent.

NOTE:  It would be nice to use a better quality program with a more natural sounding voice. In that, you'll get no argument from me! :-)

However—by using the Text-to-Speech program, I can listen to each section or paragraph. If I hear issues with words like typos, misspellings, poor grammar, or other problems, I can correct them in the text quickly and simply re-run and record it again. The T2S program allows me to save each paragraph as a separate MP3 file which loads easily and quickly into the Screencast scripting editor, which then serves as the basis for me to "follow-along" with on-screen chores.

As for the largeness of the IDE—Thomas pointed that out as well. My current solution is to make the IDE window smaller on my screen, which results in a larger more Playskool-ish video presentation. Moreover, if one is a programmer and getting lost by seeing the entire IDE, then one perhaps ought to "get-over-it" and learn the IDE, eh? I am being a bit snide and sarcastic, but we are talking about "programmers" here and not grade school kids.

Smile!

Larry Rix
Moonshot Software

Rocket science for everyone!

Savannah, GA

770-295-9729

[Larry Rix]

I have considered combining the white boarding with the audio. I just did not get there yet. These are all quite experimental so far. :-)

Larry Rix
Moonshot Software

Rocket science for everyone!

Savannah, GA

770-295-9729

[Berend de Boer]

>>>>> "Bertrand" == Bertrand Meyer <Bertran...@inf.ethz.ch> writes:

Bertrand> I do a Google search for “iteration in Eiffel”
Bertrand> (I – the real “I”this time – think this is the way
Bertrand> people typically work these days, they don’t go to
Bertrand> eiffel.org and obediently follow the hierarchical
Bertrand> structure).

That is exactly right. Especially when learning, you google. A good
way to capture questions would be to check those that end up at
eiffel.org.


Bertrand> If possible, give a rating for the importance of your
Bertrand> request, on a 1 to 10 (higher meaning more important)
Bertrand> scale. A low rating is not necessarily a killer --- the
Bertrand> criterion for deciding to take up a request is a mix
Bertrand> between importance and ease of implementation.

stackoverflow has this for questions, perhaps better to use
stackoverflow? Then you don't have to implement your own solution.


--
All the best,

Berend de Boer

[lrix]

This document is a first shot at documenting the across loop first. Feedback is highly welcomed!

[Woland's Cat]

that's actually pretty good as far as it goes (in fact I learned something from those rare cases), but it doesn't show the typical case of across, which is its use on a standard container like an ARRAYED_LIST or a HASH_TABLE, which I guess would account for 99% of all across loops.

- thomas

On 16/05/2018 21:27, lrix wrote:

This document is a first shot at documenting the across loop first. Feedback is highly welcomed!

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.

--

[Ian Joyner]

The across loop doc looks good, but I’d use a proportional typeface (for both text and code) and serif for body text. After all Eiffel as a language tries to get away from such (old-fastion, code) typefaces. The fixed-space font looks a bit mechanical (like the computer voice people were complaining about, and I concur). What typeface is it? It actually does look quite good for a fixed font.

[Chris Tillman]

Very nice explanation IMHO.

On Thu, May 17, 2018 at 8:27 AM, lrix <lr...@jinny.com> wrote:

This document is a first shot at documenting the across loop first. Feedback is highly welcomed!

--

You received this message because you are subscribed to the Google Groups "Eiffel Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.

--

Chris Tillman
Developer

[Bertrand Meyer]

All very interesting and insightful, thanks.

 

What about the following collective exercise: we use “across” as a testbed or blueprint for the ideal style of documentation, create a Google Doc or whatever somewhere with the current text, and everyone pitches in until we are all satisfied with the result?

 

With best regards,

 

-- Bertrand Meyer

LASER summer school, Elba island,2-10 June, bitcoin/blockchains, https://www.laser-foundation.org/school/ 

 

From: eiffel...@googlegroups.com <eiffel...@googlegroups.com> On Behalf Of Ian Joyner
Sent: Thursday, May 17, 2018 03:18
To: Eiffel Users <eiffel...@googlegroups.com>
Subject: Re: [eiffel-users] Documentation suggestions

 

The across loop doc looks good, but I’d use a proportional typeface (for both text and code) and serif for body text. After all Eiffel as a language tries to get away from such (old-fastion, code) typefaces. The fixed-space font looks a bit mechanical (like the computer voice people were complaining about, and I concur). What typeface is it? It actually does look quite good for a fixed font.

[lrix]

Hi Ian,

The doc is created using a Google docs template for "Meeting Notes (Modern Writer)". The font face is called "Source Code Pro".

Honestly, I built the document using Google docs, but the formatting (fonts, layout, etc.) will become the same formatting used in docs.eiffel.com now. So, the formatting is really moot. The core issue is content and quick learning, which I think was Bertrand's core point in his post about the across loop being missing and needing to appear at the top.

On Wednesday, May 16, 2018 at 8:17:39 PM UTC-4, i.joyner wrote:

... What typeface is it? It actually does look quite good for a fixed font.

[lrix]

Hi Bertrand,

1. You're welcome! :-)

2. I think the across loop is an excellent test bed subject, which is why I am focused on it at the moment.

3. The attached PDF is already a Google doc. I think I sent you a direct link so you can access it. If you have a gmail account, I can add you to the share on doc.

4. Do you want me to make the Google doc open to the public? That would allow any and all to access. I can set the doc to "Suggesting" mode, which would limit changes to "suggestions" that (as the owner of the doc) I can then accept or reject based on either your guidance or overall sense of the "vote"?

[lrix]

Here is a link to the Google doc that all can use.

https://docs.google.com/document/d/1n2MtkAcnMeJDgXwk65k3u2PA6pUdvapOgUgr_7aXMeY/edit?usp=sharing

[lrix]

Hi Thomas,

From your point of view, how would an example of ARRAYED_LIST or HASH_TABLE be written differently than what is presented in the document? As I understand it, the writing of an across loop is independent of the container being traversed, yes? I will concede your point that these two classes are perhaps the most traversed classes among everything that is ITERABLE and it is most likely good to see the across in that context.

[Alexander Kogtenkov]

Because at the time of writing, comments to the document are not allowed, I'm leaving one here:

I would suggest to add a note that iterating over an interval `1 |..| 10` is not efficient if it is used for iteration over some structure. In such cases, iteration over the structure should be used directly instead. I.e. instead of

   across 1 |..| list.count as ic loop
      ... -- use list [ic.item]
   end

one should use

   across list as ic loop
      ... -- use ic.item
   end

Regards,
Alexander Kogtenkov

lrix <lr...@jinny.com>:

[Alexander Kogtenkov]

For HASH_TABLE, the iteration cursor provides access to both `item` - as in other cases - and to `key`, so one can write

   across table as t do
      key := t.key
      value := t.item
   end

Alexander Kogtenkov

lrix <lr...@jinny.com>:

[Larry Rix]

Hi Alexander,

My fault—I thought I had the link set for editing. This new link will now allow edits and not just viewing.

https://docs.google.com/document/d/1n2MtkAcnMeJDgXwk65k3u2PA6pUdvapOgUgr_7aXMeY/edit?usp=sharing

Larry Rix
Moonshot Software

Rocket science for everyone!

Savannah, GA

770-295-9729

--

You received this message because you are subscribed to the Google Groups "Eiffel Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users+unsubscribe@googlegroups.com.

[Gerrit Leder]

I like it! @Alexander good point. @Irix good document and good explanation, well structured.

I did not come across "across" until now...

Gerrit

--

[lrix]

I created a new video for Across Loop with Skipping v2.

This video is human narrated by me. I suppose I just don't like the sound of my own voice narrating so much and it is much more labor on my part to "read" and "get-it-right". If I goof it up while reading, I do have to record it again. However, perhaps it is not so bad.

Here is the link:

https://youtu.be/6YAGh-R9PiM

Feedback highly encouraged. :-)

[Finnian Reilly]

Quickly Orientating non-Eiffel programmers to Eiffel

I think it is a safe assumption that 99% of people learning Eiffel already know a programming language in the list of the 7 most popular languages. If we wish to grow the Eiffel community then priority should be given to designing the documentation system so that it as painless and efficient as possible to migrate to Eiffel from the view-point of another language. I propose making a series of 7 "Rosetta-pages" for each of the most popular languages and structured as shown below, and directly link keywords and concepts to the nearest Eiffel equivalent or related concept.

Java to Eiffel Rosetta-stone

Table linking Java keywords to equivalent keywords (or concepts) in Eiffel

abstract	continue	for	new	switch
assert	default	goto	package	synchronized
boolean	do	if	private	this
break	double	implements	protected	throw
byte	else	import	public	throws
case	enum	instanceof	return	transient
catch	extends	int	short	try
char	final	interface	static	void
class	finally	long	strictfp	volatile
const	float	native	super	while

Table linking Java concepts to equivalent concepts in Eiffel

autoboxing	bytecode	casting	checked exception	class method
class variable	classpath	constructor	deprecation	downcast
encapsulation	global variable	iteration	interface	JAR file
JDK	JVM	main method	null	operator precedence
overloading	overriding	package	primitive type	unchecked exception

This is a somewhat abbreviated list of concepts for illustration purposes only. A point to note is that many terms may have no direct equivalent in Eiffel, so we need to orientate visitors to know what the relevant related concept is in Eiffel.

Example Keyword

Say for example a Java coder clicks on the import keyword. This can link to a standard explanation for languages that have some equivalent to import. The example shown is presented as a template that must be substituted with per-language words for $keyword, $language_name etc.

Keyword: $keyword
There is no direct equivalent of $keyword in Eiffel. The entire set of classes used to create program is instead defined in a project configuration file (ECF for Eiffel Configuration File). The contents of this file ensures that every class can be referenced with a unique name without the need for any name dot qualifiers like in $language_name.  Within an ECF the keyword library defines which class package (library) we wish to include in our project. There are ways to select only certain classes. Read Eiffel Configuration Files in the documentation for more details.

This is actually a good example to have chosen because it illustrates how difficult it can be to find this information even if the person knows what to search for. Observe the results of this search for "Eiffel configuration file" and you will see what I mean. (it doesn't matter if you put quotes around it or not)

https://www.eiffel.org/gcse20?x=0&y=0&q=eiffel+configuration+file

Ok, that didn't work. Let's try ECF

https://www.eiffel.org/gcse20?x=0&y=0&q=ECF

Not much better, we still can't find the relevant information in the first page.

Even Google is of little use (bearing in mind that Google tailors results per user)

https://www.google.ie/search?num=40&newwindow=1&source=hp&ei=32_9WtfVJc_WsAHb_7rQDg&q=eiffel+configuration+file&oq=eiffel+configuration+file&gs_l=psy-ab.3..33i160k1.890.6161.0.8687.28.23.1.0.0.0.214.2579.0j16j2.18.0....0...1.1.64.psy-ab..9.19.2585.0..0j0i131k1j0i30k1j0i22i30k1j0i22i10i30k1j33i21k1.0.hLbZOBUU0YQ

In fact nowhere could I find a discussion of Eiffel Configuration Files. The closest thing I could find by drilling into the documentation index are these pages which don't even reference the term "Eiffel Configuration File". OK perhaps if I kept looking I will eventually find something, but my patience has already run out. Imagine how you would feel as a Java programmer coming to Eiffel for the first time.

• https://www.eiffel.org/doc/eiffelstudio/Editing%20a%20project
• https://www.eiffel.org/doc/eiffelstudio/Compiling%20and%20Executing%20a%20System
  

But with a Rosetta-page I don't need to know about the role of Eiffel configuration files in advance. I can get there directly from being familiar with the Java concept import or whatever language I am already familiar with. So I submit to you that we need a Rosetta-page for the 7 most popular languages that new comers to Eiffel will almost certainly be familiar with already.

[lrix]

I have updated the Google doc with both ARRAY and HASH_TABLE.

NOTE: I used ARRAY instead of ARRAYED_LIST because it is easier to demonstrate using a manifest array (i.e. << ... >>) than to create an ARRAYED_LIST object.

https://docs.google.com/document/d/1n2MtkAcnMeJDgXwk65k3u2PA6pUdvapOgUgr_7aXMeY/edit?usp=sharing

Feedback encouraged.

BTW: The link allows you to edit.

[lrix]

Thomas,

Please recheck the document at the link below. Scroll to the bottom part of the document and tell me what you think of the ARRAY and HASH_TABLE additions.

https://docs.google.com/document/d/1n2MtkAcnMeJDgXwk65k3u2PA6pUdvapOgUgr_7aXMeY/edit?usp=sharing

[lrix]

Alexander,

I did change the document to allow editing. I also made additions to address your concerns below.

[lrix]

Finnian,

I think a Rosetta-page is an excellent suggestion!

The excellent point is that programmers who know one of the Top-7 are approaching Eiffel from a mind filled with terms and concepts learned in their "go-to-language" of choice. They are not approaching as an Eiffel vet or even an utter novice. So, for me, this is an excellent approach. It means that Eiffel docs can be accessed through a "lens" of other languages and technologies, where one get's access along familiar lines, drawing mental links between their starting language and Eiffel.

What say the rest of you?

If all agree and Bertrand and Annie Meyer agree, I am happy to work with them (and all of you) to create such a thing. Also and not forgetting that existing Eiffel docs need to be freshened and reworked somewhat, which is my current tasking.

Kind Regards,

Larry

[Jonathan Ostroff]

Finian:

Great idea! 

Is it possible to have two-way tables so that when programmers see Eiffel constructs they might reference the Java analogue to help their comprehension with the Eiffel?

Jonathan

[Anthony W]

I can only add my perspective as someone who has used C# and Java for many years, and has dabbled in Eiffel off and on over the years with a desire to use it as a primary tool.

I can figure out the majority of the language and constructs on my own, but translating common idioms/programming constructs from Eiffel -> some other language (C# for example) accelerates the understanding -- e.g. event handling via agents. Seeing an example in both languages side by side is very helpful.

The biggest hurdle for me has always been "How do I use Eiffel in conjunction with another technology?" IMO, very few systems, if any, are standalone - they rely on something else. 

For example, I've been building a trading platform which uses Interactive Brokers' API. The API can be targeted using Java, C++, C#, and Python (I think?). It requires multithreading, and I want to have a GUI and database. The most logical solution for me is to use .NET and Eiffel.

I spent hours trying to figure out "How to use Eiffel and C# winforms" together. No luck.

I spent more hours trying to figure out "How to use Eiffels multithreading (SCOOP and traditional) with .NET's multithreading." No luck.

So as much as I wanted to use Eiffel I simply couldn't gain any traction, and finally decided to just stick with C# - because it has MANY examples for accomplishing the tasks I needed to.

Honestly, I thought I was too dumb to grok the interfacing between the technologies... until Larry posted some of his frustrations a few months back.

TLDR;

Eiffel already has a GREAT hook for expanding the user base, in that it's a .NET compliant language, and more examples of how to interface with .NET as a technology would flatten the learning curve for people trying to jump ship to Eiffel. To me, getting the fundamentals seems pretty straightforward, and there is a good amount of expert technical discussion available for the advanced users. It's the bridging of technologies that needs more explanation/videos/discussion.

Anthony

Jonathan

To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users+unsubscribe@googlegroups.com.

[Woland's Cat]

On 17/05/2018 12:21, 'Alexander Kogtenkov' via Eiffel Users wrote:
> For HASH_TABLE, the iteration cursor provides access to both `item` -
> as in other cases - and to `key`, so one can write
>
>    across table as t do
>       key := t.key
>       value := t.item
>    end
>
> Alexander Kogtenkov

Larry, this is the standard form. Although I tend to use xx_csr as the
iterator name, as in

across thing_list as thing_csr do
    ... thing_csr.item
end

- thomas

[Larry Rix]

Anthony,

I agree that a Rosetta-code with strong examples that "work-the-first-time-every-time" would accelerate adoption of Eiffel into mainstream projects. I will have to look into the fastest and best roads to getting Eiffel-to-C#.NET hooked up.

Larry Rix
Moonshot Software

Rocket science for everyone!

Savannah, GA

770-295-9729

[Larry Rix]

I think it might be possible, but (of course) we want people flowing from Other-language-to-Eiffel and not so much the other way around (e.g. we're not here to teach Java to Eiffel programmers, eh?) :-)

Larry Rix
Moonshot Software

Rocket science for everyone!

Savannah, GA

770-295-9729

Jonathan

To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users+unsubscribe@googlegroups.com.

Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users+unsubscribe@googlegroups.com.

[Ian Joyner]

Hi Larry,

Thanks for the information. It is quite a nice format as it goes - for ‘notes’.

But for more serious, published document, monospaced typefaces are a big step back to the early 1980s.

I agree content is the most important, but that is not a reason to ignore the formatting (or an excuse to shut down anyone who raises the topic), which will express the ideas better by not getting in the way.

Seems like Google is now trying to do a Microsoft by inventing its own fonts constrained by technology, rather than technology adapting to the old tried-and-tested fonts, mainly designed to be beautiful in any medium. Fonts like Arial and Verdana are cases in point - although for Verdana, Bob Carter is a well-respected font designer, but he designed it to look alright on old low-res displays on the web.

Ian

[Jonathan Ostroff]

I think it might be possible, but (of course) we want people flowing from Other-language-to-Eiffel and not so much the other way around (e.g. we're not here to teach Java to Eiffel programmers, eh?) :-)

In the reverse view:

Eiffel Java

DbC No, but there are asserts

MI No

user infix ops No

expanded/value semantics No, limited to basic types

type safety Less than Eiffel due to casting etc.

void safety On its way?

consistent genericity mixed bag?

BON diagrams UML (but without some necessary seamless machinery)

…

BON diagrams are actually quite powerful for design-level documentation (see OOSC2 and TOL for many examples). Might be nice to use in some of the documentation mentioned below. 

Java has very many good features (and the advantage of rich libraries) so this is not a flame :-) 

Jonathan

To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

[Woland's Cat]

That list may have added to it lambdas. In Eiffel, function currying works, so that an agent with partly filled arguments generates a new agent with a new signature; this doesn't work in Java 8, you just have fixed lambdas (which are neverthelss pretty useful, compared to previous versions of Java).

Java on the other hand has streams, enumerated types, and probably a few more things these days that Eiffel does not.

I think BON is not relevant. We use UML in our openEHR specifications (MagicDraw), but post-process the representation to generate Eiffel-like class definitions in the specifications. The correct approach today for diagramming would be to generate UML diagrams from the code and/or use it in the forward direction the way we do. I can describe the tricks we do if anyone is interested. Essentially though, since UML failed on its original promise to do full-cycle engineering (there is no way it could ever have worked due a) to the UML meta-model, and b) problems in target languages), it is now just a drawing formalism. This is actually a good thing because it means post-processing it like we do doesn't get in anyone's way.

- thomas

[Gerrit Leder]

Hello Irix,

BTW: across would be in Ruby:

[ 1, 3, 5 ].each { |i| puts i }

Perhaps Ruby is something for the Rosetta pages?

Gerrit

Jonathan