=?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>On 2/21/2022 10:19 AM, Scott Dorsey wrote:
>> Academics shouldn't be teaching programming languages, they should be
>> teaching programming concepts. If you know C or Pascal, learning
>> how to write the procedure division code in COBOL should be a matter
>> of a couple hour's study. Once you know the concepts, learning the
>> syntax is easy. (Frustrating, perhaps, because the COBOL syntax is
>> so horrible, but easy.)
>>
>> So, I don't think there is any need to teach the programming part of
>> COBOL in school.
>
>Learning the basic building blocks of variables, if, loops and
>call are relative easy. Most people can learn that stuff.

You should try teaching Freshman programming to football players if you
think this is easy. There's a thing that happens in the head to turn
on understanding of programming flow, and once it happens it becomes
easy but getting it to happen to the uninitiated is sometimes hard.

>There are more difficult topics. Some that I know cause a
>lot of problems for people to grasp are:
>- covariant and contravariant generic types
>- currying and partially applied functions
>
>Note that those are not language specific either - they can
>be shown in different languages - even though far from all
>languages support them.

You bet!

It gets even more interesting when you talk about things like garbage
collection and coroutines which are language features but rely on specific
operating system features as well. You can't talk about one without the
other. But you have to talk about them because they are important.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 2/21/2022 12:18 PM, Scott Dorsey wrote:

> You should try teaching Freshman programming to football players if you
> think this is easy. There's a thing that happens in the head to turn
> on understanding of programming flow, and once it happens it becomes
> easy but getting it to happen to the uninitiated is sometimes hard.

I've always thought this is the key.

People expect other people to understand some basic things. What one has to
learn is that the computer doesn't understand anything. One must plan and
implement things step by step, with very basic steps.

It is when the light bulb in their head comes on that they are ready to tell a
computer what to do.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

John Dallman <jgd@cix.co.uk> wrote:
>In article <sv0ah4$fuk$1@panix2.panix.com>, kludge@panix.com (Scott
>Dorsey) wrote:
>
>> Academics shouldn't be teaching programming languages, they should
>> be teaching programming concepts.
>
>However, getting those concepts thoroughly absorbed requires applying
>them, which means writing and running programs in some actual language.
>The trick there is to avoid your students getting the idea that the
>language you use is any kind of One True Way.

Amen!
It's nice to have an algorithm description language to use for reference
but it's VERY important to let students know the algorithm description
language isn't necessarily even a usable programming language.

>The way my course deal with that was to introduce new languages regularly.
>It was a three-year course: in 1980-81, we did Pascal and an artificially
>simplified low-level language, vaguely analogous to Knuth's MIX. In
>1981-82, we did 8080 assembler, Algol68, FORTRAN and COBOL. In 1982-83,
>we did whatever was required by the options we'd chosen: I did C and more
>FORTRAN, and 6502 assembler as a hobby project.

Yes! This is very specifically noted in the ACM standard curriculum.

When I was an undergrad, every class in the program seemed to be using a
different language and a different operating system, and it was definitely
useful training to see how different systems did different things. It's
still quite easy to expose students to a variety of programming languages
although much harder now to expose them to a variety of operating systems.

>My first job required me to learn Coral66, which I'd mastered before the
>course I was supposed to go on started - it's a very simple Algol subset.
>The second job was 6502 assembler and later on, BCPL and C. Since then
>Perl, shell scripts, domain-specific languages, more assembly languages,
>LISP, a little Objective-C, and avoiding Java.

Someday you'll need to write Java. It's like the baby food version of C.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 2022-02-21, Scott Dorsey <kludge@panix.com> wrote:
>
> Academics shouldn't be teaching programming languages, they should be
> teaching programming concepts. If you know C or Pascal, learning
> how to write the procedure division code in COBOL should be a matter
> of a couple hour's study. Once you know the concepts, learning the
> syntax is easy. (Frustrating, perhaps, because the COBOL syntax is
> so horrible, but easy.)
>

Syntax is only one small part of it. Understanding the reason for the
language is very important as well.

For example, you can write C code with Ada syntax by declaring everything
as Integer or you can learn the Ada type system and start using the Ada
way of thinking to model your problem using Ada's type system.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

In article <sv0ah4$fuk$1@panix2.panix.com>,
Scott Dorsey <kludge@panix.com> wrote:
>Academics shouldn't be teaching programming languages, they should be
>teaching programming concepts. If you know C or Pascal, learning
>how to write the procedure division code in COBOL should be a matter
>of a couple hour's study. Once you know the concepts, learning the
>syntax is easy. (Frustrating, perhaps, because the COBOL syntax is
>so horrible, but easy.)
>
>So, I don't think there is any need to teach the programming part of
>COBOL in school.
>
>What's interesting about COBOL is that there is a big data description
>language attached to it, and the data description language is different
>than anything else students will have seen. So I think it's important
>to at least talk about COBOL (and maybe RPG) because some of the basic
>paradigms behind it are different than that of a canonical programming
>language.
>
>But I don't think this should take more than a day or two in a programming
>language survey class, because once students understand the basic concepts
>they can figure it out on their own if they need it.
>
>Understanding the basic concepts, though, is important to figure out how
>some modern systems got to be the way they are today.
>
>It doesn't matter whether a thing is dead or not, it matters whether a
>thing can be used to teach useful concepts. Real CS programs are about
>teaching concepts, not methods. It's expected that students can learn
>methods as needed.

Really well put. I agree on all counts, though I might say that
academics should be teaching computer science; consider theory,
for example, which is important but independent of many languages.

Certainly, algorithmic thinking that could be directly translated
to programming skills should be emphasized.

- Dan C.

In article <sv0obg$mnm$1@panix2.panix.com>,
Scott Dorsey <kludge@panix.com> wrote:
>John Dallman <jgd@cix.co.uk> wrote:
>[snip]
>Someday you'll need to write Java. It's like the baby food version of C.

It's funny, when I was in high school someone scolded me for
basically saying that I would pick the most appropriate language
for the problem at hand. Some technician dragged me through the
mud saying, basically, "you'll program in whatever language your
manager tells you to."

Curiously, that never really happened. Nowdays, I'm happy that
I'm senior enough that I can largely decide these things for
myself.

I did spend a year and change programming in Java. The language
itself isn't terrible, though verbose. However, it does seem to
be attached to what one might call a culture of excessive
abstraction. It sure seemed like an excessive amount of code is
dedicated to various kinds of machinery plugging in providers,
adapters, and all sorts of GoF design patterns, without actually
doing much of anything. :-/ "At what point do we actually add
these two numbers together?" "Oh, you just implement this
interface and create a factory that plugs into this DI framework
and that code is generated for you."

- Dan C.

On 2/21/2022 12:18 PM, Scott Dorsey wrote:
> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>> On 2/21/2022 10:19 AM, Scott Dorsey wrote:
>>> Academics shouldn't be teaching programming languages, they should be
>>> teaching programming concepts. If you know C or Pascal, learning
>>> how to write the procedure division code in COBOL should be a matter
>>> of a couple hour's study. Once you know the concepts, learning the
>>> syntax is easy. (Frustrating, perhaps, because the COBOL syntax is
>>> so horrible, but easy.)
>>>
>>> So, I don't think there is any need to teach the programming part of
>>> COBOL in school.
>>
>> Learning the basic building blocks of variables, if, loops and
>> call are relative easy. Most people can learn that stuff.
>
> You should try teaching Freshman programming to football players if you
> think this is easy. There's a thing that happens in the head to turn
> on understanding of programming flow, and once it happens it becomes
> easy but getting it to happen to the uninitiated is sometimes hard.

It is 35 years since I taught Fortran and Pascal, but as I remembered
it then 75% of students in general and 99% of students that were good
at math could learn it.

>> There are more difficult topics. Some that I know cause a
>> lot of problems for people to grasp are:
>> - covariant and contravariant generic types
>> - currying and partially applied functions
>>
>> Note that those are not language specific either - they can
>> be shown in different languages - even though far from all
>> languages support them.
>
> You bet!
>
> It gets even more interesting when you talk about things like garbage
> collection and coroutines which are language features but rely on specific
> operating system features as well. You can't talk about one without the
> other. But you have to talk about them because they are important.

Coroutines is obviously tricky.

I think the "don't worry about deallocating memory - it will be done
for you" approach feels quite natural for many beginners.

Arne

In article <sv0pgj$66b$4@dont-email.me>,
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>On 2022-02-21, Scott Dorsey <kludge@panix.com> wrote:
>> Academics shouldn't be teaching programming languages, they should be
>> teaching programming concepts. If you know C or Pascal, learning
>> how to write the procedure division code in COBOL should be a matter
>> of a couple hour's study. Once you know the concepts, learning the
>> syntax is easy. (Frustrating, perhaps, because the COBOL syntax is
>> so horrible, but easy.)
>
>Syntax is only one small part of it. Understanding the reason for the
>language is very important as well.
>
>For example, you can write C code with Ada syntax by declaring everything
>as Integer or you can learn the Ada type system and start using the Ada
>way of thinking to model your problem using Ada's type system.

How's the old quip go; you can write FORTRAN in any language?

It takes time and experience to learn to use a language
idiomatically, which is why it's important to foster a culture
of mentorship and growth, even in industry.

I've been programming most frequently in Rust for the last three
or so years, and I've observed a pattern amongst programmers who
are new to Rust: first, one starts writing C and C++ in Rust
syntax; we called this "crust" on my last project; this stage is
often associated with "fighting the borrow checker." Then, one
reaches the point where all of a sudden traits and newtypes are
really, really cool. After that, then you start writing decent
idiomatic code.

- Dan C.

On 2/21/2022 3:04 PM, Dan Cross wrote:
> In article <sv0obg$mnm$1@panix2.panix.com>,
> Scott Dorsey <kludge@panix.com> wrote:
>> John Dallman <jgd@cix.co.uk> wrote:
>> [snip]
>> Someday you'll need to write Java. It's like the baby food version of C.
>
> It's funny, when I was in high school someone scolded me for
> basically saying that I would pick the most appropriate language
> for the problem at hand. Some technician dragged me through the
> mud saying, basically, "you'll program in whatever language your
> manager tells you to."
>
> Curiously, that never really happened. Nowdays, I'm happy that
> I'm senior enough that I can largely decide these things for
> myself.
>
> I did spend a year and change programming in Java. The language
> itself isn't terrible, though verbose. However, it does seem to
> be attached to what one might call a culture of excessive
> abstraction. It sure seemed like an excessive amount of code is
> dedicated to various kinds of machinery plugging in providers,
> adapters, and all sorts of GoF design patterns, without actually
> doing much of anything. :-/ "At what point do we actually add
> these two numbers together?" "Oh, you just implement this
> interface and create a factory that plugs into this DI framework
> and that code is generated for you."

Classic example is probably creating an XML document.

C#:

XmlDocument doc = new XmlDocument();
doc.Load(XML_FILE);

Java:

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
DocumentBuilder db = dbf.newDocumentBuilder();
Document doc = db.parse(new File(XML_FILE));

Arne

On 2/21/2022 3:10 PM, Dan Cross wrote:
> In article <sv0pgj$66b$4@dont-email.me>,
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>> For example, you can write C code with Ada syntax by declaring everything
>> as Integer or you can learn the Ada type system and start using the Ada
>> way of thinking to model your problem using Ada's type system.
>
> How's the old quip go; you can write FORTRAN in any language?

When we discussed this last year I posted this "Pacsal":

PROGRAM GOTOFUN(INPUT,OUTPUT);
LABEL L731,L113,L247,L588,L761,L922,L399,L601;
VAR LBL:INTEGER;
VAR I:INTEGER;
BEGIN
L731: GOTO L113;
LBL:=399;
L113: I:=0;
WRITELN(I);
L247: LBL:=601;
IF(I<0)THEN GOTO L588 ELSE IF(I=0)THEN GOTO L922 ELSE GOTO L399;
L588: I:=I+1;
WRITELN(I);
GOTO L399;
L761: CASE(LBL)OF 399: GOTO L399; 601: GOTO L601; END;
L922: I:=I+1;
WRITELN(I);
CASE(I)OF 1: GOTO L588; 2: GOTO L399; 3: GOTO L922; END;
L399: GOTO L761;
L601: END.

> It takes time and experience to learn to use a language
> idiomatically, which is why it's important to foster a culture
> of mentorship and growth, even in industry.

Arne

In article <memo.20220221204042.7708D@jgd.cix.co.uk>,
John Dallman <jgd@cix.co.uk> wrote:
>In article <suod1l$qrm$1@reader1.panix.com>,
>cross@spitfire.i.gajendra.net (Dan Cross) wrote:
>
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> >And since it will be LLVM based then it must be x86-64 only.
>>
>> Why do you say that? Just in the sense that they won't
>> backport to OpenVMS/Itanium or Alpha? LLVM has backends
>> for non-x86 architectures.
>
>The Alpha backend for LLVM was dropped in 2018, and there's never been
>one for Itanium.

There was one for Itanium, but it was dropped in the 00's.

Again, the point was that LLVM is not x86-only.

- Dan C.

Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>I did spend a year and change programming in Java. The language
>itself isn't terrible, though verbose. However, it does seem to
>be attached to what one might call a culture of excessive
>abstraction. It sure seemed like an excessive amount of code is
>dedicated to various kinds of machinery plugging in providers,
>adapters, and all sorts of GoF design patterns, without actually
>doing much of anything. :-/ "At what point do we actually add
>these two numbers together?" "Oh, you just implement this
>interface and create a factory that plugs into this DI framework
>and that code is generated for you."

I am sorry to report that although this issue (which I refer to as
the Library Disease) is rampant among Java "programmers" it is just
as severe among python "programmers" and increasingly becoming an
issue with C++ "programmers."

I have had people tell me that sorting was much faster in Java
because it could be done in one line whereas it took many lines
of C code. The degree to which this exposes fundamental misunderstandings
about computing amazes me.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 2/21/2022 2:34 PM, Simon Clubley wrote:
> On 2022-02-21, Scott Dorsey <kludge@panix.com> wrote:
>>
>> Academics shouldn't be teaching programming languages, they should be
>> teaching programming concepts. If you know C or Pascal, learning
>> how to write the procedure division code in COBOL should be a matter
>> of a couple hour's study. Once you know the concepts, learning the
>> syntax is easy. (Frustrating, perhaps, because the COBOL syntax is
>> so horrible, but easy.)
>>
>
> Syntax is only one small part of it. Understanding the reason for the
> language is very important as well.
>
> For example, you can write C code with Ada syntax by declaring everything
> as Integer or you can learn the Ada type system and start using the Ada
> way of thinking to model your problem using Ada's type system.
>
> Simon.
>

Why does any of that have to be tied to any language?

Concepts and procedures is what is important.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 2/21/2022 5:44 PM, Dave Froble wrote:
> On 2/21/2022 2:34 PM, Simon Clubley wrote:
>> On 2022-02-21, Scott Dorsey <kludge@panix.com> wrote:
>>> Academics shouldn't be teaching programming languages, they should be
>>> teaching programming concepts.  If you know C or Pascal, learning
>>> how to write the procedure division code in COBOL should be a matter
>>> of a couple hour's study.  Once you know the concepts, learning the
>>> syntax is easy.  (Frustrating, perhaps, because the COBOL syntax is
>>> so horrible, but easy.)
>>>
>>
>> Syntax is only one small part of it. Understanding the reason for the
>> language is very important as well.
>>
>> For example, you can write C code with Ada syntax by declaring everything
>> as Integer or you can learn the Ada type system and start using the Ada
>> way of thinking to model your problem using Ada's type system.
>
> Why does any of that have to be tied to any language?
>
> Concepts and procedures is what is important.

Yes.

They should really learn that there are different approaches to types:
* dynamic typing
* implicit static typing
* explicit static typing with basic types and composite types
* static typing with possibility of constrained basic types

There are multiple languages available for example sin each category.

Arne

On 2022-02-21, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 2/21/2022 5:44 PM, Dave Froble wrote:
>> On 2/21/2022 2:34 PM, Simon Clubley wrote:
>>> On 2022-02-21, Scott Dorsey <kludge@panix.com> wrote:
>>>> Academics shouldn't be teaching programming languages, they should be
>>>> teaching programming concepts.  If you know C or Pascal, learning
>>>> how to write the procedure division code in COBOL should be a matter
>>>> of a couple hour's study.  Once you know the concepts, learning the
>>>> syntax is easy.  (Frustrating, perhaps, because the COBOL syntax is
>>>> so horrible, but easy.)
>>>>
>>>
>>> Syntax is only one small part of it. Understanding the reason for the
>>> language is very important as well.
>>>
>>> For example, you can write C code with Ada syntax by declaring everything
>>> as Integer or you can learn the Ada type system and start using the Ada
>>> way of thinking to model your problem using Ada's type system.
>>
>> Why does any of that have to be tied to any language?
>>
>> Concepts and procedures is what is important.
>

And having enough knowledge to choose the best language for the job and
having enough knowledge to understand that other languages are not just
C with a different syntax is also important.

> Yes.
>
> They should really learn that there are different approaches to types:
> * dynamic typing
> * implicit static typing
> * explicit static typing with basic types and composite types
> * static typing with possibility of constrained basic types
>
> There are multiple languages available for example sin each category.
>

They should also learn that type systems are a way to help you
make a program more robust and not just "something to be dealt with".

This is as much about acquiring the correct mindset as it is about
acquiring knowledge.

Ada has the best type system I have ever used, but that's no good
if you don't know enough, or have the correct mindset, in order to
take full advantage of it.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2/17/2022 5:17 PM, Arne Vajhøj wrote:
> On 2/17/2022 4:41 PM, Dave Froble wrote:
>> On 2/17/2022 3:10 PM, Arne Vajhøj wrote:
>>> On 2/17/2022 2:39 PM, Bill Gunshannon wrote:
>>>> On 2/17/22 14:17, Arne Vajhøj wrote:
>>>>> On 2/17/2022 1:59 PM, Dave Froble wrote:
>>>>>> I'd like to know just who and what the "industry" Arne refers to
>>>>>> is? It's
>>>>>> always easy to use some nebulous term.  But just what is it?
>>>>>> Perhaps it is a
>>>>>> "transfer", as in "transfer your money to us"?
>>>>>
>>>>> It is all those companies using IT. And the decisions they make.
>>>>
>>>> You mean all those people running zSystems with COBOL, DB2 and CICS
>>>> that actually make up the largest majority of the money makers in the
>>>> world?  The ones who have been told for at least 4 decades that the
>>>> mainframe is dead.  Oh yeah, and so is COBOL.
>>>
>>> The IT industry also include those.
>>>
>>> But in the big picture they are a tiny part of the IT industry. And
>>> not only a tiny part but also a shrinking part.
>>
>> Arne, when you offer an opinion, please identify it as "opinion".
>
> That mainframe is a tiny portion of IT today is not an
> opinion - it is a fact. You can start by looking at
> sales figures.

As an illustration: Fujitsu will stop selling mainframes
in 2030 and stop support in 2035.

https://www.pcgamer.com/50-of-transactions-were-fraudulent-when-steam-accepted-bitcoin-for-payments-says-gabe-newell/

(and they are also ditching Solaris/Sparc in 2029 and 2034)

Arne

Den 2022-02-27 kl. 02:47, skrev Arne Vajhøj:
> On 2/17/2022 5:17 PM, Arne Vajhøj wrote:
>> On 2/17/2022 4:41 PM, Dave Froble wrote:
>>> On 2/17/2022 3:10 PM, Arne Vajhøj wrote:
>>>> On 2/17/2022 2:39 PM, Bill Gunshannon wrote:
>>>>> On 2/17/22 14:17, Arne Vajhøj wrote:
>>>>>> On 2/17/2022 1:59 PM, Dave Froble wrote:
>>>>>>> I'd like to know just who and what the "industry" Arne refers to is?
>>>>>>> It's
>>>>>>> always easy to use some nebulous term.  But just what is it? Perhaps
>>>>>>> it is a
>>>>>>> "transfer", as in "transfer your money to us"?
>>>>>>
>>>>>> It is all those companies using IT. And the decisions they make.
>>>>>
>>>>> You mean all those people running zSystems with COBOL, DB2 and CICS
>>>>> that actually make up the largest majority of the money makers in the
>>>>> world?  The ones who have been told for at least 4 decades that the
>>>>> mainframe is dead.  Oh yeah, and so is COBOL.
>>>>
>>>> The IT industry also include those.
>>>>
>>>> But in the big picture they are a tiny part of the IT industry. And
>>>> not only a tiny part but also a shrinking part.
>>>
>>> Arne, when you offer an opinion, please identify it as "opinion".
>>
>> That mainframe is a tiny portion of IT today is not an
>> opinion - it is a fact. You can start by looking at
>> sales figures.
>
> As an illustration: Fujitsu will stop selling mainframes
> in 2030 and stop support in 2035.
>
> https://www.pcgamer.com/50-of-transactions-were-fraudulent-when-steam-accepted-bitcoin-for-payments-says-gabe-newell/
>
>
> (and they are also ditching Solaris/Sparc in 2029 and 2034)
>
> Arne
>
>
>

I do not see that the link supports that claim.

On 2/27/2022 7:24 AM, Jan-Erik Söderholm wrote:
> Den 2022-02-27 kl. 02:47, skrev Arne Vajhøj:
>> On 2/17/2022 5:17 PM, Arne Vajhøj wrote:
>>> On 2/17/2022 4:41 PM, Dave Froble wrote:
>>>> On 2/17/2022 3:10 PM, Arne Vajhøj wrote:
>>>>> On 2/17/2022 2:39 PM, Bill Gunshannon wrote:
>>>>>> On 2/17/22 14:17, Arne Vajhøj wrote:
>>>>>>> On 2/17/2022 1:59 PM, Dave Froble wrote:
>>>>>>>> I'd like to know just who and what the "industry" Arne refers to
>>>>>>>> is? It's
>>>>>>>> always easy to use some nebulous term.  But just what is it?
>>>>>>>> Perhaps it is a
>>>>>>>> "transfer", as in "transfer your money to us"?
>>>>>>>
>>>>>>> It is all those companies using IT. And the decisions they make.
>>>>>>
>>>>>> You mean all those people running zSystems with COBOL, DB2 and CICS
>>>>>> that actually make up the largest majority of the money makers in the
>>>>>> world?  The ones who have been told for at least 4 decades that the
>>>>>> mainframe is dead.  Oh yeah, and so is COBOL.
>>>>>
>>>>> The IT industry also include those.
>>>>>
>>>>> But in the big picture they are a tiny part of the IT industry. And
>>>>> not only a tiny part but also a shrinking part.
>>>>
>>>> Arne, when you offer an opinion, please identify it as "opinion".
>>>
>>> That mainframe is a tiny portion of IT today is not an
>>> opinion - it is a fact. You can start by looking at
>>> sales figures.
>>
>> As an illustration: Fujitsu will stop selling mainframes
>> in 2030 and stop support in 2035.
>>
>> https://www.pcgamer.com/50-of-transactions-were-fraudulent-when-steam-accepted-bitcoin-for-payments-says-gabe-newell/
>>
>> (and they are also ditching Solaris/Sparc in 2029 and 2034)
>
> I do not see that the link supports that claim.

Copy paste error. Sorry.

https://www.theregister.com/2022/02/25/fujitsu_signposts_the_end_for

Arne

On 2/27/22 08:43, Arne Vajhøj wrote:
> On 2/27/2022 7:24 AM, Jan-Erik Söderholm wrote:
>> Den 2022-02-27 kl. 02:47, skrev Arne Vajhøj:
>>> On 2/17/2022 5:17 PM, Arne Vajhøj wrote:
>>>> On 2/17/2022 4:41 PM, Dave Froble wrote:
>>>>> On 2/17/2022 3:10 PM, Arne Vajhøj wrote:
>>>>>> On 2/17/2022 2:39 PM, Bill Gunshannon wrote:
>>>>>>> On 2/17/22 14:17, Arne Vajhøj wrote:
>>>>>>>> On 2/17/2022 1:59 PM, Dave Froble wrote:
>>>>>>>>> I'd like to know just who and what the "industry" Arne refers
>>>>>>>>> to is? It's
>>>>>>>>> always easy to use some nebulous term.  But just what is it?
>>>>>>>>> Perhaps it is a
>>>>>>>>> "transfer", as in "transfer your money to us"?
>>>>>>>>
>>>>>>>> It is all those companies using IT. And the decisions they make.
>>>>>>>
>>>>>>> You mean all those people running zSystems with COBOL, DB2 and CICS
>>>>>>> that actually make up the largest majority of the money makers in
>>>>>>> the
>>>>>>> world?  The ones who have been told for at least 4 decades that the
>>>>>>> mainframe is dead.  Oh yeah, and so is COBOL.
>>>>>>
>>>>>> The IT industry also include those.
>>>>>>
>>>>>> But in the big picture they are a tiny part of the IT industry. And
>>>>>> not only a tiny part but also a shrinking part.
>>>>>
>>>>> Arne, when you offer an opinion, please identify it as "opinion".
>>>>
>>>> That mainframe is a tiny portion of IT today is not an
>>>> opinion - it is a fact. You can start by looking at
>>>> sales figures.
>>>
>>> As an illustration: Fujitsu will stop selling mainframes
>>> in 2030 and stop support in 2035.
>>>
>>> https://www.pcgamer.com/50-of-transactions-were-fraudulent-when-steam-accepted-bitcoin-for-payments-says-gabe-newell/
>>>
>>> (and they are also ditching Solaris/Sparc in 2029 and 2034)
>>
>> I do not see that the link supports that claim.
>
> Copy paste error. Sorry.
>
> https://www.theregister.com/2022/02/25/fujitsu_signposts_the_end_for
>

I don't think it says what people are expected to believe it says.
Looks like more business for IBM as a small player not making much
profit exits the market. The only two large players in the mainframe
world are IBM and Unisys and Unisys only has a fraction of that
market. IBM is not going away any time soon.

bill

On 27/02/2022 14:51, Bill Gunshannon wrote:
> On 2/27/22 08:43, Arne Vajhøj wrote:
>> On 2/27/2022 7:24 AM, Jan-Erik Söderholm wrote:
>>> Den 2022-02-27 kl. 02:47, skrev Arne Vajhøj:
>>>> On 2/17/2022 5:17 PM, Arne Vajhøj wrote:
>>>>> On 2/17/2022 4:41 PM, Dave Froble wrote:
>>>>>> On 2/17/2022 3:10 PM, Arne Vajhøj wrote:
>>>>>>> On 2/17/2022 2:39 PM, Bill Gunshannon wrote:
>>>>>>>> On 2/17/22 14:17, Arne Vajhøj wrote:
>>>>>>>>> On 2/17/2022 1:59 PM, Dave Froble wrote:
>>>>>>>>>> I'd like to know just who and what the "industry" Arne refers
>>>>>>>>>> to is? It's
>>>>>>>>>> always easy to use some nebulous term.  But just what is it?
>>>>>>>>>> Perhaps it is a
>>>>>>>>>> "transfer", as in "transfer your money to us"?
>>>>>>>>>
>>>>>>>>> It is all those companies using IT. And the decisions they make.
>>>>>>>>
>>>>>>>> You mean all those people running zSystems with COBOL, DB2 and CICS
>>>>>>>> that actually make up the largest majority of the money makers
>>>>>>>> in the
>>>>>>>> world?  The ones who have been told for at least 4 decades that the
>>>>>>>> mainframe is dead.  Oh yeah, and so is COBOL.
>>>>>>>
>>>>>>> The IT industry also include those.
>>>>>>>
>>>>>>> But in the big picture they are a tiny part of the IT industry. And
>>>>>>> not only a tiny part but also a shrinking part.
>>>>>>
>>>>>> Arne, when you offer an opinion, please identify it as "opinion".
>>>>>
>>>>> That mainframe is a tiny portion of IT today is not an
>>>>> opinion - it is a fact. You can start by looking at
>>>>> sales figures.
>>>>
>>>> As an illustration: Fujitsu will stop selling mainframes
>>>> in 2030 and stop support in 2035.
>>>>
>>>> https://www.pcgamer.com/50-of-transactions-were-fraudulent-when-steam-accepted-bitcoin-for-payments-says-gabe-newell/
>>>>
>>>> (and they are also ditching Solaris/Sparc in 2029 and 2034)
>>>
>>> I do not see that the link supports that claim.
>>
>> Copy paste error. Sorry.
>>
>> https://www.theregister.com/2022/02/25/fujitsu_signposts_the_end_for
>>
>
> I don't think it says what people are expected to believe it says.
> Looks like more business for IBM as a small player not making much
> profit exits the market.  The only two large players in the mainframe
> world are IBM and Unisys and Unisys only has a fraction of that
> market.  IBM is not going away any time soon.
>
> bill
>
>

I can't see it meaning any more business for IBM. I believe that a lot
of Fujitsu mainframe was the UK government or other UK companies that
bought ICL kit, because the had no choice, and ICL was then bought by
Fujitsu.

The ICL VME environment is totally different to IBM mainframes and its
as complex to migrate it to IBM as it is to move to Linux or Windows.

However its not clear to me what the above means for VME which Fujitsu
seems to have re-defined from "Virtual Machine Environment" as "Virtual
Managed Environment" but it still seems to run the original code..

https://www.ukauthority.com/articles/hmrc-sticks-with-fujitsu-for-virtual-environment/

very odd, perhaps Fujitsu no longer considers this to be "mainframes....

Dave

On 2/27/2022 9:51 AM, Bill Gunshannon wrote:
> On 2/27/22 08:43, Arne Vajhøj wrote:
>> https://www.theregister.com/2022/02/25/fujitsu_signposts_the_end_for
>
> I don't think it says what people are expected to believe it says.
> Looks like more business for IBM as a small player not making much
> profit exits the market.

Fujitsu is leaving the mainframe market.

But they are not selling their mainframe business - they are shutting
it down.

You can conclude something about the mainframe market from that. Fujitsu
does not see a way to make a profit in the future and potential buyers
do not see it either.

>   The only two large players in the mainframe
> world are IBM and Unisys and Unisys only has a fraction of that
> market.  IBM is not going away any time soon.

IBM is doing fine. They have a huge consultancy business and
a big software business and a medium cloud business.

The system division which is z, p and i are only 12%
of their revenue.

But IBM will not drop the mainframe market for a few
decades to come. But revenue from that market will
continue to decline.

Arne

=?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>Fujitsu is leaving the mainframe market.
>
>But they are not selling their mainframe business - they are shutting
>it down.
>
>You can conclude something about the mainframe market from that. Fujitsu
>does not see a way to make a profit in the future and potential buyers
>do not see it either.

Fujitsu is really an IBM clone maker, just like NAS and Amdahl. They have
some cool features and an fancy OS/360 clone, but there is no massive
impediment to their users moving to IBM hardware if they can't move to the
Fujitsu X86 stuff (for I/O performance reasons, etc).

>>   The only two large players in the mainframe
>> world are IBM and Unisys and Unisys only has a fraction of that
>> market.  IBM is not going away any time soon.
>
>IBM is doing fine. They have a huge consultancy business and
>a big software business and a medium cloud business.

And SOON they will have all of Fujitsu's customers. It's nice work if you
can get it.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 2/28/22 15:08, Scott Dorsey wrote:
> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>> Fujitsu is leaving the mainframe market.
>>
>> But they are not selling their mainframe business - they are shutting
>> it down.
>>
>> You can conclude something about the mainframe market from that. Fujitsu
>> does not see a way to make a profit in the future and potential buyers
>> do not see it either.
>
> Fujitsu is really an IBM clone maker, just like NAS and Amdahl. They have
> some cool features and an fancy OS/360 clone, but there is no massive
> impediment to their users moving to IBM hardware

That was pretty much what I meant when I said advantage IBM. :-)

> if they can't move to the
> Fujitsu X86 stuff (for I/O performance reasons, etc).

I am not aware of any I/O performance issues with zSystems.

>
>>>   The only two large players in the mainframe
>>> world are IBM and Unisys and Unisys only has a fraction of that
>>> market.  IBM is not going away any time soon.
>>
>> IBM is doing fine. They have a huge consultancy business and
>> a big software business and a medium cloud business.
>
> And SOON they will have all of Fujitsu's customers. It's nice work if you
> can get it.

Exactly.

bill