> While I don’t explicitly mention Eiffel,
Typical Eiffel-user restraint... Maybe intellectually laudable, but the result is lost opportunities for newcomers to hear about Eiffel, not to mention endless re-invention of concepts that are present (often in a better way) in Eiffel. My suggestion is to shed the restraint and publicize Eiffel.
-- BM
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/8D497762-C02E-4658-B3C7-DD81CD962173%40acm.org.
For more options, visit https://groups.google.com/d/optout.
> While I don’t explicitly mention Eiffel,
Typical Eiffel-user restraint... Maybe intellectually laudable, but the result is lost opportunities for newcomers to hear about Eiffel, not to mention endless re-invention of concepts that are present (often in a better way) in Eiffel. My suggestion is to shed the restraint and publicize Eiffel.
At the moment I think there are too many non-language limitations to Eiffel for it to gain much traction with today's younger programmers - for now. I have pointed out many of these in the past, but essentially, the following are problematic:
Unfortunately the IT industry sails along on foundations of poor
quality, but thinks they are good enough - Java, C#, XML, XSD,
REST, JSON, UML, JS, etc. It's all low quality stuff based on
weak thinking. Economically, apparently they are good enough, if
you consider the IT to be sustainable (it's clearly horribly
inefficient, but so is the entire economy...). To work around that
probably means creating a whole technology development stack,
including language, diagramming (UML replacement), network / web
programming framework, server/DB framwork, integrated IDE, mobile
app programming, virtualisation tools etc.
It's not totally out of the question. In my openEHR work, we
replaced UML/XML with BMM,
JSON with ODIN (well, ODIN was 10y earlier than JSON),
and then we had to invent some new things not properly covered by
anything in industry, e.g. archetypes
(Schematron and ICL might be the closest attempts). Replacing the
much longer list of poor quality industry standard technologies is
going to be a serious task.
But being more realistic I think entails finding solutions to making some of the connections I list above. These are the technological connections that all /most new languages have out of the box.
If I were going to start on a path of investigating where to go
with Eiffel, I'd probably start looking at Kotlin: how does it
generate code for the JVM from its relatively advanced constructs
(e.g. FP)? What does it take to plug a language into the IntelliJ
tool? How does one connect an AngularJS app to it? etc
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/12f301d50894%24ebc97c50%24c35c74f0%24%40inf.ethz.ch.
Dear Ian,
Yes, I know… It’s unfair to pick on just this one time.
-- BM
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/D7EFC864-5C21-498A-A6EC-FDD41824CB07%40acm.org.
Dear Thomas,
Not very encouraging. Your suggestions are all correct, of course, in the sense that having all these interfaces would help, but we cannot be chasing the next “in” thing all the time. We prefer to work on the basic engine with the expectation that its superiority will convince people and that the rest will follow.
We have to choose what to interface to. The JVM was tried and the project hit a dead end because of multiple inheritance – doable in .NET, not doable in the JVM. Maybe we should try again but I see no evidence that the conceptual roadblock is gone.
.NET is an example of why interfacing to important technologies is not enough. Eiffel’s .NET implementation definitely helps, but my impression is that most people who use Eiffel on .NET pretty soon switch to native (non-.NET) Eiffel/EiffelStudio.
As a sign of the danger of focusing on the trendy interface du jour, here is a list of detailed suggestions for Eiffel you sent on 6 March 2005 (I don’t always answer your detailed suggestions, sorry, but I do read them and I have a 4-TB disk):
2. My list of things that are needed today for Eiffel are mostly to do
with integration:
- name spaces (allowing multiple libraries to be integrated)
- connection to UML that works
- integration to OCL (near future)
- automated java integration
- automated generation of XML-schemas from models (today I have to write
this myself)
- automated generation of IDL and WSDL from models
- upgraded document generation, like javadoc
- an inbuilt reflection mechanism is needed. This allows for much more
flexible information- and knowledge-driven computing.
These were all good suggestions at the time, and several remain applicable today, but I don’t think that focusing on IDL and OCL would have made much of a difference.
Interfacing to many tools is important but we need to choose. What underlies your suggestions is the need to create an ecosystem in which more than one source contributes the elements. Any suggestion to build it is welcome.
With best regards,
-- Bertrand Meyer
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/8cb84818-d73f-b35c-42ab-ba6e2d08716b%40gmail.com.
Well, I have plenty of Eiffel mentions. Here are some:Should be plenty of people beating down the doors!Ian
On 12 May 2019, at 17:32, Bertrand Meyer <Bertra...@inf.ethz.ch> wrote:
> While I don’t explicitly mention Eiffel,Typical Eiffel-user restraint... Maybe intellectually laudable, but the result is lost opportunities for newcomers to hear about Eiffel, not to mention endless re-invention of concepts that are present (often in a better way) in Eiffel. My suggestion is to shed the restraint and publicize Eiffel.-- BMFrom: eiffel...@googlegroups.com [mailto:ei...@googlegroups.com] On Behalf Of Ian Joyner
Sent: Sunday, May 12, 2019 02:44
To: Eiffel Users <eiffel...@googlegroups.com>
Subject: [eiffel-users] Quora - What is a pointer?I just responded to a question on the meaning of pointers. Ended up being another long essay. While I don’t explicitly mention Eiffel, it does explain why pointers in C and C++ are not desirable.I’m sure you guys will point out any guff.Ian
--
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...@googlegroups.com.
Visit this group at https://groups.google.com/group/eiffel-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/8D497762-C02E-4658-B3C7-DD81CD962173%40acm.org.
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...@googlegroups.com.
I say 'most' because some newly popular languages like Rust seem to concentrate on server-side programming, and maybe don't include the first capability above; similarly, front-end languages like TypeScript may not do everything in the 3rd category, but certainly satisfy 1. and 2.
On the problem of MI and a VM, I would have thought the directions of investigation might be:
The second is an idea I have often wondered about but never had time to investigate: applying the curried function idea to converting an MI lineage to an SI one, i.e. by progressively synthesising classes that each inherit from only one other class, while defining a set of features of one parent of each class that originally had multiple parents. I assume this has been thought about and analysed, probably years ago, but I have never seen any discussion about it. Maybe it can't be shown to work. In any case, quite a bit of Eiffel MI is to do with inheriting classes full of constants; some is also pure abstract inheritance. Is there no way to map this onto the single inheritance extends/implements system required by Java?
I also don't make any assumption that all or any work implied by my comments should only be done by one party.
One other thing that all new programmers expect, probably since at least the days of Python, is a community, with meetups, conferences, hackathons and other very practical ways of engaging.
regards
- thomas
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/003501d50966%24d8251240%24886f36c0%24%40inf.ethz.ch.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/003d01d50968%24fa9623d0%24efc26b70%24%40inf.ethz.ch.
Maybe Eiffel MI is not implementable on top of the raw JVM. But I just realised you could probably write an Eiffel runtime on top of JVM that handles dispatch to MI tables. Of course this is another layer of indirection (isn’t there a saying about that?).
ANSI C *or* JVM – true of EiffelStudio too.
-- BM
From: eiffel...@googlegroups.com <eiffel...@googlegroups.com> On Behalf Of Peter Gummer
Sent: Monday, May 13, 2019 15:58
To: 'Alexander Kogtenkov' via Eiffel Users <eiffel...@googlegroups.com>
Subject: Re: [eiffel-users] Quora - What is a pointer?
Ian Joyner <i.jo...@acm.org> wrote:
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/E4D946A1-1B74-4282-AED6-9EF88C0DC22B%40bigpond.net.au.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/00ee01d5098c%2426080970%2472181c50%24%40inf.ethz.ch.
Dear Thomas,
...
.NET is an example of why interfacing to important technologies is not enough. Eiffel’s .NET implementation definitely helps, but my impression is that most people who use Eiffel on .NET pretty soon switch to native (non-.NET) Eiffel/EiffelStudio.
....
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/003d01d50968%24fa9623d0%24efc26b70%24%40inf.ethz.ch.
Bootstrapping a language to popularity
What does every popular language have in common? I would argue that
they all first successfully occupied a niche for a while, and then after
building up a solid base of support, overflowed the niche to gain
popularity. Building up a solid base is essentially a question of
economics. Success in the niche is initially established by a superior
design for that niche. This create the conditions for an economy to
emerge of many paying jobs requiring knowledge of the language. Once
enough developers are being financially rewarded for developing with the
language, it creates a strong incentive to contribute libraries of a
professional standard. A critical mass of libraries then paves the way
for more widespread acceptance as a general purpose language.
Here are some examples, with niche being understood to mean original niche. (Some languages occupied a number of niches either successively or simultaneously.)
Ada
Niche: super robust language for Pentagon projects that must not fail
C
Niche: a compact portable high-level language that had similar performance to assembly
Niche: a language that is backwards compatible with C but has OO features.
Java
Niche:
C#
Niche: a VM language exhibiting many of the advantages of Java, but controlled by Microsoft and therefore guaranteed to work better on all Windows platforms and tools
Python
Niche:
Eiffel
Niche: ???
Has Eiffel ever fulfilled an original niche? I am not sure that it did. It seems to me that Eiffel tried to leapfrog past being in any niche, and become a general purpose language from the get go. Consequently it failed to build up a large enough base of paid developers who could create a critical mass of libraries to catapult it to widespread popularity.
What would be a natural niche for Eiffel? I was reading this FAQ from
a company offering training in the DO-178 standard for avionics coding.
Which software language is best for avionics software?
High order languages (requiring a compiler with complex syntax construction capabilities) are strongly preferred as they are simply safer. Safe avionics software? Yes, DO-178 emphasizes code consistency, visibility, determinism, defensive coding, robustness, requirements and design traceability, software peer reviews per detailed checklists, thorough testing via structural coverage and real-world asynchronous testing.
Per the above, avionics code is best written in Ada, C and C++. With all languages, a safe subset should be used. Ada was the former defacto avionics language standard, and Ada95 improved the Objected Oriented capabilities. However, the tide is behind C and C++; not because of inherent superiorities, but rather the wider availability of development tools and engineers able to develop real-time embedded C and C++.
I find that last statement quite jaw dropping!
"emphasizes code consistency, visibility, determinism, defensive coding, robustness, requirements and design traceability,"This sounds like the natural competitive strength of Eiffel. Based on the above, I could imagine some subset of Eiffel conforming to DO-178 and being marketed to the avionics industry as the language that combines the best of Ada, C and C++ and then some.
On 15 May 2019, at 23:41, Finnian Reilly <frei...@gmail.com> wrote:
Which software language is best for avionics software?
High order languages (requiring a compiler with complex syntax construction capabilities) are strongly preferred as they are simply safer. Safe avionics software? Yes, DO-178 emphasizes code consistency, visibility, determinism, defensive coding, robustness, requirements and design traceability, software peer reviews per detailed checklists, thorough testing via structural coverage and real-world asynchronous testing.
Per the above, avionics code is best written in Ada, C and C++. With all languages, a safe subset should be used. Ada was the former defacto avionics language standard, and Ada95 improved the Objected Oriented capabilities. However, the tide is behind C and C++; not because of inherent superiorities, but rather the wider availability of development tools and engineers able to develop real-time embedded C and C++.
I find that last statement quite jaw dropping!
"emphasizes code consistency, visibility, determinism, defensive coding, robustness, requirements and design traceability,"This sounds like the natural competitive strength of Eiffel. Based on the above, I could imagine some subset of Eiffel conforming to DO-178 and being marketed to the avionics industry as the language that combines the best of Ada, C and C++ and then some.
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/e305f29a-be18-47fd-9b65-e944af24a0aa%40googlegroups.com.
Finnian—sounds like some marketing money and effort needs to be applied!
The total budget for 2019 is estimated at €3.78 million. The total grant awarded can range from €10,000 to €150,000 and must be 50% match funded.
This scheme is for companies who have produced at least one recently published video game who wish to invest in the development of a new video game concept or prototype.
This scheme supports European independent video games companies with proven experience who want to develop up to an alpha or beta version of a narrative-led video game.
Apparently, Kotlin is a German animal.
President: Andrey Breslav (JetBrains)
Secretary: Max Sills (Google)
Board of Directors:
Lead Language Designer: Andrey Breslav (JetBrains)
Language Committee:
-------- Original Message --------
Subject: Re: [eiffel-users] Quora - What is a pointer?
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/361090d6-f754-e8bc-ea30-b1b86f76fbfc%40gobosoft.com.
What should be the features of the new language? What did you decide to bet on? What should have been a competitive advantage, since there have already been attempts to create an “alternative to Java”?
- There are several key aspects of the language on which the cost of its "operation" depends, that is, the costs of companies that will write in this language. First, if the language is very complex, then programmers who write on it will have to pay a large salary. Secondly, if programs are difficult to understand, if they are difficult to look for errors in them and make changes, then development is delayed and becomes more expensive. Thirdly, if programs turn out to be slow due to the properties of the language, you have to invest in their acceleration (from hiring expensive optimization specialists to buying faster hardware).
Therefore, Kotlin is a fairly easy-to-learn language, and the average programmer who works for the average wage can easily master it. The syntax of the language, the type system and the instrumental support make it easy to use, so the productivity of developers is very high (higher than in Java). For example, data classes, properties, type inference, and many other features of the language allow you to write (and therefore read) less code for typical tasks, the built-in control of null references and the smart casts mechanism help earlier and faster to detect errors, and flexible abstractions (extension functions , functional types, etc.) allow you to reuse more code. In addition, programs are as fast as Java (sometimes even a little faster).
Among the pre-existing languages for the Java platform, this combination did not occur: other languages are too expensive for a wide class of projects. Java is too “verbose”, so the code is harder to read, write and modify, and Kotlin also eliminates some types of errors that are often found in Java programs. Scala is too complicated, only expensive specialists can use it well. Groovy is too slow for many tasks and error prone. Each language has its own niche, in which it is very good, just a question about the size of this niche. For Kotlin, it is very large, for other alternative languages - somewhat already.
On 18 May 2019, at 01:06, Larry Rix <lar...@moonshotsoftware.com> wrote:Without a doubt, Eiffel is a European child!
On 18 May 2019, at 01:06, Larry Rix <lar...@moonshotsoftware.com> wrote:
Without a doubt, Eiffel is a European child! America and other countries have contributed only a small part of the whole, but the origin and idea are wholly and fully European! So—if the EU has funding that could be tapped, then I am all for folks in Europe to make that happen.
Apparently, Kotlin is a German animal. I'd love to see elegant French technology find its proper success!
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/c6de2643-d82f-48ae-a506-86bef5fc6d45%40googlegroups.com.
-------- Original Message --------
Subject: Re: [eiffel-users] Quora - What is a pointer?
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/C4D3CAA8-6452-49A4-B63B-537A2773915C%40acm.org.
Thanks Ian. Good stuff.
Perhaps we (and I very much include myself in this) techno-geezers need to step back from our walkers for a moment and smell the <whatever dumb-ass coffee-like abomination is popular today>.
That I believe is the scientific description of what is found in
places like you-know-where...
The state of computing might have differed with geography and politics, at some point, somewhere, but the state of computing today (lamentable most certainly) has nothing to do with those factors, and has not for quite some time.If you were to ask the typical "software professional" (and not our FOG*), what they know about hardware, or computing in general, and you'd get a very sad response. We have, I fear, succeeded in creating abstraction to the point of absurdity (see: ifttt.com) and as such, there is a small percentage of the profession that can be called "system programmers" simply because most have either retired or died, and fewer are needed. The ranks of scripters, in contrast, has swollen.We have achieved the dream of "software ICs", and it's a nightmare (for some of us).It's not that there is no value in such grunt-and-point-and-Voila programming. There is a lot of value to its consumers, and good salaries for its practitioners. The problem is, it's not the value some of us seek.Timeliness is the fashion, and fashion drives the planet these days. There are, I hope, a few islands of awareness; pockets of resistance, where the Goodness of software still matters.
Agree... the signs of bad software and poor languages are very simple: a) too many lines of code for a given task, b) unmaintainability and c) lack of correctness (bugs, or catastrophes, in Ariane 5 or Boeing 737 Max). Everything else stems from those things. They more or less define the unnecessary inefficiency of the IT economy.
I was just studying Kotlin's
idea of inheritance, constructors etc, and I kept thinking:
this is unnecessarily complex to do a relatively simple job. And
it doesn't even have MI (crippled by the JVM). There seems to be a
level of hacking that goes on in language design, just like in
normal code, which results in mess like Scala, Java 8+, Kotlin
(slightly better) and so on. Lots of useful features, but badly
designed, badly integrated, too many alternative syntax options
... apparently language designers don't study formal logic
anymore.
In my domain (health information systems and standards) it's
exactly the same, and I have no doubt that most people here see
the same in your respective domains - most things are badly done,
with little concern for anything other than local islands of work
and functionality. It simply doesn't matter to most people that
doing things properly would probably reduce the cost of software
globally by a factor of 10, while greatly improving the quality.
The fact is, most people don't care about quality. Or possibly, even know what it looks like. This I put down to the lack of ability for abstraction, and particularly to see negative downstream consequences of poor languages, code etc being built today The latter requires a mental ability to infer from specific kinds of bad code, constructs etc, what the results in running systems and maintenance effort will be over the next 5+ years. Most people it seems can't do that. It's probably no mistake that the main character in Zen and the Art of Motorcycle Maintenance is more than slightly crazy by the end - no-one else seems to care about quality.
So this is the world we live in. Which is why I think that the popularity of Eiffel rests on mundane considerations of being more easily able to write a web app in TypeScript (or why not EiffelScript?) for a mobile device on an Eiffel back-end, deploy it in a modern virtualised container, and (somehow) make it work on the *%&^ JVM.
- thomas
-------- Original Message --------
Subject: Re: [eiffel-users] Quora - What is a pointer?
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/8b6063ff-fb74-0ffe-2821-81d5e2aabc4b%40gmail.com.
All nicely put.As much as I'd love to be able to web-app my way to happiness with Eiffel, I worry that only a handful of the faithful would care. It might be a better use of resources to build on what Eiffel does best, to create conspicuous value in contexts where that matters (objectively, and in the minds of its denizens).While avionics and autonomous vehicles demand (we hope) the qualities that Eiffel brings, they are also near-real-time, or actual real-time systems, and that has, traditionally, been an area where things like garbage collection were seen as the spawn of Satan.Practitioners of RT and NRT systems know that it ain't the reality or or time that's the issue; it's the predictable latency. A slower, but predictably so, system can be managed, but an unpredictable one (w/r/t latency) cannot.A GC system, including Eiffel's could be made to be more predictable, assuming that the memory consumption patterns are also. That's a tall order.
well there are different classes of 'real time'. I first ordered Eiffel in 1988 for the company I worked for (Leeds and Northrup, now Foxboro) to experiment with it, for distributed real-time control (SCADA) systems. The time domain of the scanning remote units is usually in the 1 second area, occasionally in high ms range. This is because most of these systems are scanning things like gas pressure changes, transformer tap changes, circuit breaker state changes, train movement changes. The O(1sec) is fine for most things, with O(10ms) - O(100ms) occasionally needed. All this is far slower than the cycle time of any modern GC running on a normal processor. Eiffel would be perfect for this. After I left the company, they went for C++ (from C, which was what I wanted to replace). Now, C++ is an evil language (like Portuguese, Russian, Vietnamese and a few others) but can be spoken well by those with the right schooling, so you can do what you need in C++, you just have to be super-careful, and build a team just around GC/memory leaks.
For telecoms / network switches etc, the time domain is certainly
in the micro-seconds - low milliseconds range, so knowing what the
GC is doing does start becoming a question. For on-board avionics
you're definitely in the time domain where an interruption by the
GC at the wrong time might be a problem. But, as with anything
there are practical heuristics. For example, it's not that hard to
determine when a plane is in steady, stable flight, and a GC and
some other things could be allowed to run and consume a few ms of
CPU.
Does it mean Eiffel Software should be pitching to control systems, avinics and telecoms companies? Maybe... it would be an interesting question as to how Eiffel would rate compared to what ESA or NASA currently use for example.
- thomas
Garbage collector accelerators are on their way. See IEEE Micro Vol 39 Issue 3 may-June 2019, p 38
From: eiffel...@googlegroups.com <eiffel...@googlegroups.com>
On Behalf Of Woland's Cat
Sent: Sunday, 19 May 2019 03:12
To: eiffel...@googlegroups.com
Subject: Re: [eiffel-users] Quora - What is a pointer?
On 18/05/2019 17:34, r...@amalasoft.com wrote:
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/583b9355-9e2e-1c15-21d9-01b2b9007c9e%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/20190518055114.cf48dd763fcaf5d42559c6c92f6fc53b.7ce52c12ad.wbe%40email25.godaddy.com.
On 19 May 2019, at 02:34, r...@amalasoft.com wrote:
an area where things like garbage collection were seen as the spawn of Satan
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/20190518093422.cf48dd763fcaf5d42559c6c92f6fc53b.728c14df82.wbe%40email25.godaddy.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/FEDAC240-4A72-4F9D-AF14-737D188C331C%40acm.org.
this is also how standards development at ISO and HL7 work: everything is consensus-based +loudest voice wins (well ISO also has bloc-voting like Eurovision - to create technical standards!). Problem is the consensus usually only has a weak relationship with truth or reality, unless it's only surgeons, pilots or nuclear power station employees in the room. The result of this is that there are official standards in e-health that are objectively just wrong in the terms of their own technical formalisms.
I find good quality red wine sometimes helps …
- thomas
On 19/05/2019 02:30, Ian Joyner wrote:
On 19 May 2019, at 02:34, r...@amalasoft.com wrote:an area where things like garbage collection were seen as the spawn of Satan
Countering widely held beliefs like this is difficult. Essential bounds checking for correctness and security put down as training wheels. Nefarious notions of ‘programmer freedom’. These are all arguments I have tried to identify and argue against. People don’t like exploring what the alternatives are or considering to a sufficiently deep level. I quoted John Iliffe’s paper yesterday – from personal correspondence with someone who corresponds with Iliffe it seems he withdrew from computing very disillusioned. I’m glad to see that others like Bertrand, Tony Hoare and others stick to the same message. But how to break down this wall, which adversely affects everything, not just Eiffel.
I heard a radio program the other day researching how to change people’s opinions. This has certainly been more than demonstrated in this country yesterday with the election here. It showed that all the party that won had to do was to put around a lot of lies, misinformation, fake news to scare people off. It is very sad this worked – and democracy is considerably weakened. I certainly observe that in discussions (arguments) I have on Quora that opponents defending their cherished beliefs (GC spawn of satan) quickly become abusive and it seems they discuss in the tactic that loudest person wins – just like the continuing PM here. It is sad that such tactics have a habit of prevailing.
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/eiffel-users/68347cd0-752c-f594-7cab-d02177fc1a3e%40gmail.com.