std::string str ("Nobody cares about development...");

Khamon

Folk Harpist
Joined
Sep 23, 2018
Messages
2,274
Location
Alabama
SL Rez
2003
Joined SLU
2007
Is that IBM's JCL? Many long years ago I took a PL/C course where the programs were run on a mainframe. We had to preface the program with a JCL template, that told the mainframe which department/class to "bill" and that we were submitting a PL/C program to be run and printed out. Yes, to see if our program worked as it was supposed to do, we had to go fetch the output from the printing office at the computing center. No punch cards though, we used IBM terminals with weirdo function keys.
We had one puncher, and had to complete a single punch card assignment, because teacher Burroughs nostalgia et al. That required walking the drawer over to the CC in the Admin Building basement and picking up the output a day or two later. Our main terminals were DECwriters so, thank goodness, we could produce our own listings and output on ye olde green bar paperz. But there were no screens. Barbarians we were.
 
  • 1Interesting
Reactions: CronoCloud Creeggan

Argent Stonecutter

Emergency Mustelid Hologram
Joined
Sep 20, 2018
Messages
5,279
Location
Coonspiracy Central, Noonkkot
SL Rez
2005
Joined SLU
Sep 2009
SLU Posts
20780
Is that IBM's JCL? Many long years ago I took a PL/C course where the programs were run on a mainframe. We had to preface the program with a JCL template, that told the mainframe which department/class to "bill" and that we were submitting a PL/C program to be run and printed out. Yes, to see if our program worked as it was supposed to do, we had to go fetch the output from the printing office at the computing center. No punch cards though, we used IBM terminals with weirdo function keys.
Yes, that was IBM's job control gibberish.

That was my first job, in COBOL, except that it was Honeywell's job control gibberish rather than IBM's. Remember when Honeywell made their own computers?

This was when I was still in high school.

We didn't actually punch cards. Instead we wrote editor commands on a coding template, which were sent out to get punched, the cards came back later that day and we desk-checked them and got to use the single in-facility punch if we found a card wrong. Then we submitted our edit jobs, with Honeywell's job control gibberish to tell it what files to edit and how to compile them, and then finally we got printouts.

They did deliver the printouts to us, at least.

We typically got two runs a day.

When I got to college the mandatory first CS class was Fortran, with punch cards. I tested out of it despite never having seen Fortran before, so I could use the UNIX system.
 
Last edited:
  • 1Like
Reactions: CronoCloud Creeggan

Free

sapiens gratis
VVO Supporter 🍦🎈👾❤
Joined
Sep 22, 2018
Messages
31,473
Location
Moonbase Caligula
SL Rez
2008
Joined SLU
2009
SLU Posts
55565
Young programmer: There were computer languages before C?

Old programmer #1: I remember sorting beads on an abacus to track corn stock.

Old programmer #2: I used to have to play tom-toms to send out control messages over the air.
 

CronoCloud Creeggan

Redheaded
VVO Supporter 🍦🎈👾❤
Joined
Sep 26, 2018
Messages
1,420
Location
Central Illinois
SL Rez
2006
Joined SLU
07-25-2012
SLU Posts
278
Young programmer: There were computer languages before C?

Old programmer #1: I remember sorting beads on an abacus to track corn stock.

Old programmer #2: I used to have to play tom-toms to send out control messages over the air.
I think I'm the young one in this instance, even though I'm not a programmer. I saw home/micro computers years before I ever saw a mainframe-connected terminal and by that time of 1985 they were screens.
We typically got two runs a day.
Sadface.
When I got to college the mandatory first CS class was Fortran, with punch cards. I tested out of it despite never having seen Fortran before, so I could use the UNIX system.
Ooh, you had skillz, to test out of that Fortran class.
 

Free

sapiens gratis
VVO Supporter 🍦🎈👾❤
Joined
Sep 22, 2018
Messages
31,473
Location
Moonbase Caligula
SL Rez
2008
Joined SLU
2009
SLU Posts
55565
I think I'm the young one in this instance, even though I'm not a programmer.
I'm one of the "young" programmers. I know about the likes of Fortran and COBOL and machine code and punch cards and so on, but I learned about them through my learning C and other 'modern' computer languages.

But that's not funny.
 

Khamon

Folk Harpist
Joined
Sep 23, 2018
Messages
2,274
Location
Alabama
SL Rez
2003
Joined SLU
2007
I think I'm the young one in this instance, even though I'm not a programmer. I saw home/micro computers years before I ever saw a mainframe-connected terminal and by that time of 1985 they were screens.
I could connect from home with my handy dandy external 300 baud Hayes modem and have a screen. But it tied up the phone line, cut into my BBS time, and meant that I had to go pick up the output the next day. We did have twinax terminals available when I went back to school, after leaving school to earn money, not my best decision.
 

Argent Stonecutter

Emergency Mustelid Hologram
Joined
Sep 20, 2018
Messages
5,279
Location
Coonspiracy Central, Noonkkot
SL Rez
2005
Joined SLU
Sep 2009
SLU Posts
20780
Was that Twinax the manufacturer or did it use twinax cable for long distance serial connections?
 

CronoCloud Creeggan

Redheaded
VVO Supporter 🍦🎈👾❤
Joined
Sep 26, 2018
Messages
1,420
Location
Central Illinois
SL Rez
2006
Joined SLU
07-25-2012
SLU Posts
278
I'm one of the "young" programmers. I know about the likes of Fortran and COBOL and machine code and punch cards and so on, but I learned about them through my learning C and other 'modern' computer languages.

But that's not funny.
Code:
#include <stdio.h>

main()
{
      { 
          printf ("Who says C isn't funny?\n");
          printf ("Look at all these curly braces, it's unnatural I say.\n");
      }
}
 

Veritable Quandry

Specializing in derails and train wrecks.
Joined
Sep 19, 2018
Messages
4,000
Location
Columbus, OH
SL Rez
2010
Joined SLU
20something
SLU Posts
42
We had one puncher, and had to complete a single punch card assignment, because teacher Burroughs nostalgia et al. That required walking the drawer over to the CC in the Admin Building basement and picking up the output a day or two later. Our main terminals were DECwriters so, thank goodness, we could produce our own listings and output on ye olde green bar paperz. But there were no screens. Barbarians we were.
Never used punch cards, but my high school programming class had five dial-in terminals that printed on greenbar for a class of 20ish students. We did Fortran on the district mainframe. Most of class time was used on logic, diagramming programs on paper first. There was no storage space on the system so we kept to short programs.
 
  • 1Like
Reactions: Khamon

bubblesort

Well-known member
Joined
Nov 16, 2018
Messages
1,993
I've been tinkering around with html and css, and I thought I found a bug. If you put an h1 inside an article or a section, it gets smaller, and looks like an h2. If you nest the articles and sections, it keeps getting smaller and smaller! You can see the effect here. If you want to reverse the shrinking, uncomment the css. That css has to be included if you want to put a normal looking h1 inside a semantic tag like an article or section.

If you nest like this in divs, though, you don't have to worry about that extra formatting overhead in your CSS.

So I dug around to see if this is a bug or what, and turns out, the standards guys did this deliberately, because they think it's a great idea to put multiple h1 tags in a document. So I guess you make all your headings h1, and they get formatted based on how far nested they are in semantic tags. Mind you, they did not change h2-h6 to behave like this, just h1, because I guess h1 is a more exciting tag, or something?

This is just dumb. I mean, I know to expect this behavior now, but having multiple h1 tags is stupid. I'm probably going to stick to using divs from now on. Either that or use h1 for every heading and rely on semantic tags to structure everything right? I'm not sure what to make of it.
 
Joined
Sep 19, 2018
Messages
5,735
Location
NJ suburb of Philadelphia
SL Rez
2003
SLU Posts
4494
I've been tinkering around with html and css, and I thought I found a bug. If you put an h1 inside an article or a section, it gets smaller, and looks like an h2. If you nest the articles and sections, it keeps getting smaller and smaller! You can see the effect here. If you want to reverse the shrinking, uncomment the css. That css has to be included if you want to put a normal looking h1 inside a semantic tag like an article or section.

If you nest like this in divs, though, you don't have to worry about that extra formatting overhead in your CSS.

So I dug around to see if this is a bug or what, and turns out, the standards guys did this deliberately, because they think it's a great idea to put multiple h1 tags in a document. So I guess you make all your headings h1, and they get formatted based on how far nested they are in semantic tags. Mind you, they did not change h2-h6 to behave like this, just h1, because I guess h1 is a more exciting tag, or something?

This is just dumb. I mean, I know to expect this behavior now, but having multiple h1 tags is stupid. I'm probably going to stick to using divs from now on. Either that or use h1 for every heading and rely on semantic tags to structure everything right? I'm not sure what to make of it.
I don't quite see how you come to your conclusions. Disclaimer: I am hardly an expert on this stuff.

At any rate, if your html is pasted into the w3c markup validation service the following warning is returned:

Warning: Consider using the h1 element as a top-level heading only (all h1 elements are treated as top-level headings by many screen readers and other tools).

Following that link gives:

Usage notes
  • Heading information can be used by user agents to construct a table of contents for a document automatically.
  • Avoid using heading elements to resize text. Instead, use the CSS font-size property.
  • Avoid skipping heading levels: always start from <h1>, followed by <h2> and so on.
  • Use only one <h1> per page or view. It should concisely describe the overall purpose of the content.
  • Using more than one <h1> will not result in an error, but is not considered a best practice. It is beneficial for screenreader users, and SEO.
  • While HTML5 allows a <h1> per sectioning element, it is not considered best practice, and may subvert the expectations of how screen reader users navigate.
As a further note, html makes a distinction between structural markup and presentational markup. h1 tags are an example of structural markup. As is noted in HTML - Wikipedia

There are several types of markup elements used in HTML:

Structural markup indicates the purpose of text. For example, <h2>Golf</h2> establishes "Golf" as a second-level heading. Structural markup does not denote any specific rendering, but most web browsers have default styles for element formatting. Content may be further styled using Cascading Style Sheets (CSS).[72]

Presentational markup indicates the appearance of the text, regardless of its purposeFor example, <b>bold text</b> indicates that visual output devices should render "boldface" in bold text, but gives little indication what devices that are unable to do this (such as aural devices that read the text aloud) should do. In the case of both <b>bold text</b> and <i>italic text</i>, there are other elements that may have equivalent visual renderings but that are more semantic in nature, such as <strong>strong text</strong> and <em>emphasized text</em> respectively. It is easier to see how an aural user agent should interpret the latter two elements. However, they are not equivalent to their presentational counterparts: it would be undesirable for a screen-reader to emphasize the name of a book, for instance, but on a screen such a name would be italicized. Most presentational markup elements have become deprecated under the HTML 4.0 specification in favor of using CSS for styling.
 
  • 1Thanks
Reactions: bubblesort

bubblesort

Well-known member
Joined
Nov 16, 2018
Messages
1,993
I don't quite see how you come to your conclusions. Disclaimer: I am hardly an expert on this stuff.

At any rate, if your html is pasted into the w3c markup validation service the following warning is returned:

Warning: Consider using the h1 element as a top-level heading only (all h1 elements are treated as top-level headings by many screen readers and other tools).

Following that link gives:

Usage notes
  • Heading information can be used by user agents to construct a table of contents for a document automatically.
  • Avoid using heading elements to resize text. Instead, use the CSS font-size property.
  • Avoid skipping heading levels: always start from <h1>, followed by <h2> and so on.
  • Use only one <h1> per page or view. It should concisely describe the overall purpose of the content.
  • Using more than one <h1> will not result in an error, but is not considered a best practice. It is beneficial for screenreader users, and SEO.
  • While HTML5 allows a <h1> per sectioning element, it is not considered best practice, and may subvert the expectations of how screen reader users navigate.
As a further note, html makes a distinction between structural markup and presentational markup. h1 tags are an example of structural markup. As is noted in HTML - Wikipedia

There are several types of markup elements used in HTML:

Structural markup indicates the purpose of text. For example, <h2>Golf</h2> establishes "Golf" as a second-level heading. Structural markup does not denote any specific rendering, but most web browsers have default styles for element formatting. Content may be further styled using Cascading Style Sheets (CSS).[72]

Presentational markup indicates the appearance of the text, regardless of its purposeFor example, <b>bold text</b> indicates that visual output devices should render "boldface" in bold text, but gives little indication what devices that are unable to do this (such as aural devices that read the text aloud) should do. In the case of both <b>bold text</b> and <i>italic text</i>, there are other elements that may have equivalent visual renderings but that are more semantic in nature, such as <strong>strong text</strong> and <em>emphasized text</em> respectively. It is easier to see how an aural user agent should interpret the latter two elements. However, they are not equivalent to their presentational counterparts: it would be undesirable for a screen-reader to emphasize the name of a book, for instance, but on a screen such a name would be italicized. Most presentational markup elements have become deprecated under the HTML 4.0 specification in favor of using CSS for styling.
Yeah, that's how I learned it, too. Then I wrote a web site to experiment around with. Here it is. The only links that work on it right now are Home and Blog.

The only reason my h1 heading looks correct is because I explicitly styled it with CSS to be 2ems high and have the appropriate margin, like all h1s are supposed to have. It's kind of weird that I have to explicitly state that an h1 is 2 ems high, though, right? I had to add all this to override the browser...

Code:
h1 {
    display: block;
    font-size: 2em;
    margin-block-start: 0.67em;
    margin-block-end: 0.67em;
    margin-inline-start: 0px;
    margin-inline-end: 0px;
    font-weight: bold;
}
Why? Turns out, this is the product of lots of people arguing over semantic html. Here's just one argument I uncovered.

So the new conventional wisdom is that h1 tags can be headings for articles, rather than headings for entire pages. Nest it in one level and h1 looks like h2, two levels and h1 looks like h3, and so on. h2-h6 don't respond that way, but h1 is special for semantics. I guess they want to use h1 instead of h2 in news feed and blog headings? Here's a stack overflow page where somebody explains it.

So if I don't want to use CSS to fix the h1 on my blog page, I should replace the section tags around the sidebars and main content section with divs, then replace the article tags around my section with an h1 with divs, so my h1 has no semantic tags around it. Then I need to use articles for the posts under it, and either continue using h2, because h2 behaves as expected, or use h1 to title every blog post, like the guy on stack overflow described, because the h1 is treated as an h2 if it's in an article tag.
 

bubblesort

Well-known member
Joined
Nov 16, 2018
Messages
1,993
I've been stuck for weeks on flexbox alignment and justification. I was about to give up, but decided to try to make a web page to demonstrate all the justification and alignment properties available in flexbox, to at least document where the problems are, so maybe I can find a pattern or something and figure out where I'm going wrong. It took me two days to write it, and right when I was about to do the last property I tried loading it in Firefox. Up until that point I had only used Chrome. Turns out, most of the broken things worked fine in Firefox!

So I made a table of properties, and whether they work in Firefox, Chrome or both, and stuck it to the top of my examples page, and published it all here.

It's probably not much use to people who know what they are doing. If anybody can give advice on what I'm doing wrong in any of the CSS, let me know.

Right now, I plan to move on, and study grid layouts a bit, then learn JavaScript. I assume there is a way to deal with cross-browser issues like this more elegantly with JavaScript.
 

Argent Stonecutter

Emergency Mustelid Hologram
Joined
Sep 20, 2018
Messages
5,279
Location
Coonspiracy Central, Noonkkot
SL Rez
2005
Joined SLU
Sep 2009
SLU Posts
20780
This looks like the baselines are lined up, Firefox on Mac:



Also, in an earlier example, I would expect giving it two contradictory alignments (self-start and self-end) would be undefined behavior.
 

bubblesort

Well-known member
Joined
Nov 16, 2018
Messages
1,993
This looks like the baselines are lined up, Firefox on Mac:



Also, in an earlier example, I would expect giving it two contradictory alignments (self-start and self-end) would be undefined behavior.
LOL, of course it works on mac. *head desk* I thought LSL was buggy, but web development is worse. I mean, I am used to losing weeks of my life to bugs in LSL, but at least with LSL, when something is broken, it's reliably broken. With CSS, it's broken for differently for different people.

As for the contradictory alignments... it took me a while to come up with that, so I hope I'm doing it right. The idea is to use the cascade rules to change the default alignment before setting the alignment I want to test. In other words, among CSS properties with the same priority, the last property set is what gets used. If I do <p style="color:green; color:blue;">, the paragraph will be blue. If I do <p style="color:blue; color:green;", the paragraph will be green.

I used it for justification, for example, because the default justification is flex-start. How do I know if setting justify-content:flex-start works, or if it's just ignoring that and using default justification? In both cases, the result is justifictaion to flex-start. So I set flex-end, then flex-start. If my flex-start value is ignored, then the alignment falls back to flex-end, so I know it's broken. Flex-start is not broken, by the way, but that's how I know it's not broken.
 
  • 1Like
Reactions: Khamon

bubblesort

Well-known member
Joined
Nov 16, 2018
Messages
1,993
This looks like the baselines are lined up, Firefox on Mac:



Also, in an earlier example, I would expect giving it two contradictory alignments (self-start and self-end) would be undefined behavior.
Oh, wait, I just double checked... align-items:last baseline; works in firefox for windows as well! That was an oversight on my part. Thank you for catching that, I'm going to update the web page now. It's still broken in Chrome, but it works in Firefox.

EDIT: It's updated now. To see the changes, I had to use ctrl-F5 to make Chrome dump the cached version with the bad info, and load the page fresh.
 
Last edited:
  • 1Like
Reactions: Khamon