www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - This thread on Hacker News terrifies me

reply Walter Bright <newshound2 digitalmars.com> writes:
https://news.ycombinator.com/item?id=17880722

Typical comments:

"`assertAndContinue` crashes in dev and logs an error and keeps going in prod. 
Each time we want to verify a runtime assumption, we decide which type of
assert 
to use. We prefer `assertAndContinue` (and I push for it in code review),"

"Stopping all executing may not be the correct 'safe state' for an airplane
though!"

"One faction believed you should never intentionally crash the app"

"One place I worked had a team that was very adamant about not really having 
much error checking. Not much of any qc process, either. Wait for someone to 
complain about bad data and respond. Honestly, this worked really well for 
small, skunkworks type projects that needed to be nimble."

And on and on. It's unbelievable. The conventional wisdom in software for how
to 
deal with programming bugs simply does not exist.

Here's the same topic on Reddit with the same awful ideas:

https://www.reddit.com/r/programming/comments/9bl72d/assertions_in_production_code/

No wonder that DVD players still hang when you insert a DVD with a scratch on 
it, and I've had a lot of DVD and Bluray players over the last 20 years. No 
wonder that malware is everywhere.
Aug 31 2018
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 8/31/18 3:50 PM, Walter Bright wrote:

 https://news.ycombinator.com/item?id=17880722
 
 Typical comments:
 
 "`assertAndContinue` crashes in dev and logs an error and keeps going in 
 prod. Each time we want to verify a runtime assumption, we decide which 
 type of assert to use. We prefer `assertAndContinue` (and I push for it 
 in code review),"


e.g. D's assert. Well, actually, D doesn't log an error in production.

-Steve
Aug 31 2018
parent reply Shachar Shemesh <shachar weka.io> writes:
On 31/08/18 23:22, Steven Schveighoffer wrote:

 On 8/31/18 3:50 PM, Walter Bright wrote:

 https://news.ycombinator.com/item?id=17880722

 Typical comments:

 "`assertAndContinue` crashes in dev and logs an error and keeps going 
 in prod. Each time we want to verify a runtime assumption, we decide 
 which type of assert to use. We prefer `assertAndContinue` (and I push 
 for it in code review),"


 
 e.g. D's assert. Well, actually, D doesn't log an error in production.
 
 -Steve


I think it's the music of the thing rather than the thing itself.

Mecca has ASSERT, which is a condition always checked and that always 
crashes the program if it fails, and DBG_ASSERT, which, like D's built 
in assert, is skipped in release mode (essentially, an assert where you 
can log what went wrong without using the GC needing format).

When you compare this to what Walter was quoting, you get the same end 
result, but a vastly different intention. It's one thing to say "this 
ASSERT is cheap enough to be tested in production, while this DBG_ASSERT 
one is optimized out". It's another to say "well, in production we want 
to keep going no matter what, so we'll just ignore the asserts".

Shachar
Sep 01 2018
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 9/1/18 6:29 AM, Shachar Shemesh wrote:

 On 31/08/18 23:22, Steven Schveighoffer wrote:

 On 8/31/18 3:50 PM, Walter Bright wrote:

 https://news.ycombinator.com/item?id=17880722

 Typical comments:

 "`assertAndContinue` crashes in dev and logs an error and keeps going 
 in prod. Each time we want to verify a runtime assumption, we decide 
 which type of assert to use. We prefer `assertAndContinue` (and I 
 push for it in code review),"


 e.g. D's assert. Well, actually, D doesn't log an error in production.


 
 I think it's the music of the thing rather than the thing itself.
 
 Mecca has ASSERT, which is a condition always checked and that always 
 crashes the program if it fails, and DBG_ASSERT, which, like D's built 
 in assert, is skipped in release mode (essentially, an assert where you 
 can log what went wrong without using the GC needing format).
 
 When you compare this to what Walter was quoting, you get the same end 
 result, but a vastly different intention. It's one thing to say "this 
 ASSERT is cheap enough to be tested in production, while this DBG_ASSERT 
 one is optimized out". It's another to say "well, in production we want 
 to keep going no matter what, so we'll just ignore the asserts".


Which is exactly what Phobos and Druntime do (ignore asserts in 
production). I'm not sure how the intention makes any difference.

The obvious position of D is that asserts and bounds checks shouldn't be 
used in production -- that is how we ship our libraries. It is what the 
"-release" switch does. How else could it be interpreted?

-Steve
Sep 02 2018
prev sibling next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Friday, 31 August 2018 at 19:50:20 UTC, Walter Bright wrote:

 https://news.ycombinator.com/item?id=17880722

 Typical comments:

 "`assertAndContinue` crashes in dev and logs an error and keeps 
 going in prod. Each time we want to verify a runtime 
 assumption, we decide which type of assert to use. We prefer 
 `assertAndContinue` (and I push for it in code review),"

 "Stopping all executing may not be the correct 'safe state' for 
 an airplane though!"

 "One faction believed you should never intentionally crash the 
 app"

 "One place I worked had a team that was very adamant about not 
 really having much error checking. Not much of any qc process, 
 either. Wait for someone to complain about bad data and 
 respond. Honestly, this worked really well for small, 
 skunkworks type projects that needed to be nimble."

 And on and on. It's unbelievable. The conventional wisdom in 
 software for how to deal with programming bugs simply does not 
 exist.

 Here's the same topic on Reddit with the same awful ideas:

 https://www.reddit.com/r/programming/comments/9bl72d/assertions_in_production_code/

 No wonder that DVD players still hang when you insert a DVD 
 with a scratch on it, and I've had a lot of DVD and Bluray 
 players over the last 20 years. No wonder that malware is 
 everywhere.


You would probably enjoy this talk.

"Hayley Denbraver We Are 3000 Years Behind: Let's Talk About 
Engineering Ethics"

https://www.youtube.com/watch?v=jUSJePqplDA

I think that until lawsuits and software refunds due to 
malfunctions escalate to a critical level, the situation will 
hardly change.

Some countries do have engineering certifications and 
professional permits for software engineering, but its still a 
minority.

--
Paulo
Aug 31 2018
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Aug 31, 2018 at 08:42:38PM +0000, Paulo Pinto via Digitalmars-d wrote:

 On Friday, 31 August 2018 at 19:50:20 UTC, Walter Bright wrote:

 https://news.ycombinator.com/item?id=17880722




[...]

 And on and on. It's unbelievable. The conventional wisdom in
 software for how to deal with programming bugs simply does not
 exist.
 
 Here's the same topic on Reddit with the same awful ideas:




[...]

 Some countries do have engineering certifications and professional
 permits for software engineering, but its still a minority.


[...]

It's precisely for this reason that the title "software engineer" makes
me cringe on the one hand, and snicker on the other hand.  I honestly
cannot keep a straight face when using the word "engineering" to
describe what a typical programmer does in the industry these days.

Where are the procedures, documentations, verification processes,
safeguards, certifications, culpability, etc., etc., that make
engineering the respected profession that it is?  They are essentially
absent in typical software development environments, or only poorly aped
in the most laughable ways.  Most "enterprise" software has no proper
design document at all; what little documentation does exist is merely a
lip-service shoddy hack-job done after the fact to justify the cowboying
that has gone on before.  It's an embarrassment to call this
"engineering", and a shame to real engineers who have actual engineering
procedures to follow.

Until the software industry gets its act together and become a real,
respectable engineering field, we will continue to suffer from
unreliable software that malfunctions, eats your data, and crashes on
unusual inputs for no good reason other than that it was never properly
engineered.  And malware and catastrophic security breaches will
continue to run rampant in spite of millions and billions of dollars
being poured into improving security every year.  And of course, more
and more of modern life is becoming dependent on devices controlled by
software of such calibre (IoT... *shudder*).  It's a miracle that
society hasn't collapsed yet!


T

-- 
There are three kinds of people in the world: those who can count, and those
who can't.
Aug 31 2018
next sibling parent reply Kagamin <spam here.lot> writes:
On Friday, 31 August 2018 at 21:09:21 UTC, H. S. Teoh wrote:

 Some countries do have engineering certifications and 
 professional permits for software engineering, but its still a 
 minority.


 [...]

 It's precisely for this reason that the title "software 
 engineer" makes me cringe on the one hand, and snicker on the 
 other hand.  I honestly cannot keep a straight face when using 
 the word "engineering" to describe what a typical programmer 
 does in the industry these days.


Huh? I'm pretty sure they mean it was a management decision. Why 
do you blame engineers for doing what they are asked to do? 
Making them write code properly is as simple as paying for 
exactly that.
Sep 01 2018
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Saturday, September 1, 2018 2:19:07 AM MDT Kagamin via Digitalmars-d 
wrote:

 On Friday, 31 August 2018 at 21:09:21 UTC, H. S. Teoh wrote:

 Some countries do have engineering certifications and
 professional permits for software engineering, but its still a
 minority.


 [...]

 It's precisely for this reason that the title "software
 engineer" makes me cringe on the one hand, and snicker on the
 other hand.  I honestly cannot keep a straight face when using
 the word "engineering" to describe what a typical programmer
 does in the industry these days.


 Huh? I'm pretty sure they mean it was a management decision. Why
 do you blame engineers for doing what they are asked to do?
 Making them write code properly is as simple as paying for
 exactly that.


I think that his point was more that it's sometimes argued that software
engineering really isn't engineering in the classical sense. If you're
talking about someone like a civil engineer for instance, the engineer
applies well-known and established principles to everything they do in a
disciplined way. The engineering aspects of civil engineering aren't
subjective at all. They're completely based in the physical sciences.
Software engineering on the other hand isn't based on the physical sciences
at all, and there really isn't general agreement on what good software
engineering principles are. There are aspects of it that are very much like
engineering and others that are very much subjective.

Someone else could probably explain it better than I could, but based on
some definitions of engineering, software engineering definitely doesn't
count, but it _does_ have aspects of engineering, so it can be argued either
way. Wikipedia even has a "controversy" section on its page for software
engineering that talks briefly about it:

https://en.wikipedia.org/wiki/Software_engineering

I'm not sure that I really agree that software engineering isn't
engineering, but the folks who argue against it do have a point in that
software engineering is definitely not like most other engineering
disciplines, and good engineering practices are nowhere near as well-defined
in software engineering as those in other engineering fields.

Issues with management cause other problems on top of all of that, but even
if you have a group of software engineers doing their absolute best to
follow good software engineering principles without any kind of management
interference, what they're doing is still very different from most
engineering disciplines, and it likely wouldn't be hard for another group of
competent software engineers to make solid arguments about why the good
software engineering practices that they're following actually aren't all
that good.

- Jonathan M Davis
Sep 01 2018
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 1 September 2018 at 11:32:32 UTC, Jonathan M Davis 
wrote:

 I'm not sure that I really agree that software engineering 
 isn't engineering, but the folks who argue against it do have a 
 point in that software engineering is definitely not like most 
 other engineering disciplines, and good engineering practices 
 are nowhere near as well-defined in software engineering as 
 those in other engineering fields.


Most engineering fields have a somewhat stable/slow moving 
context in which they operate.

If you have a specific context (like banking) then you can 
develop a software method that specifies how to build banking 
software, and repeat it, assuming that the banks you develop the 
method for are similar

Of course, banking has changed quite a lot over the past 15 years 
(online + mobile). Software often operates in contexts that are 
critically different and that change in somewhat unpredictable 
manners.

But road engineers have a somewhat more stable context, they can 
adapt their methodology over time. Context does change even 
there, but at a more predictable pace.

Of course, this might be primarily because computers are new. 
Businesses tend to use software/robotics in a disruptive manner 
to get a competitive edger over the competitors. So the users 
themselves creates disruptive contexts in their search for the 
"cutting edge"  or "competitive edge".

As it becomes more and more intertwined into how people do 
business it might become more stable and then you might see 
methods for specific fields that are more like engineering in 
older established fields. (like building railways).
Sep 01 2018
parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 09/01/2018 05:06 PM, Ola Fosheim Grøstad wrote:

 
 If you have a specific context (like banking) then you can develop a 
 software method that specifies how to build banking software, and repeat 
 it, assuming that the banks you develop the method for are similar
 
 Of course, banking has changed quite a lot over the past 15 years 
 (online + mobile). Software often operates in contexts that are 
 critically different and that change in somewhat unpredictable manners.
 


Speaking of, that always really gets me:

The average ATM is 24/7. Sure, there may be some downtime, but what, how 
much? For the most part, these things were more or less reliable decades 
ago, from a time with *considerably* less of the "best practices" and 
accumulated experience, know-how, and tooling we have today. And over 
the years, they still don't seem to have screwed ATMs up too badly.

But contrast that to my bank's phone "app": This thing *is* rooted 
firmly in modern technology, modern experience, modern collective 
knowledge, modern hardware and...The servers it relies on *regularly* go 
down for several hours at a time during the night. That's been going on 
for the entire 2.5 years I've been using it.

And for about an hour the other day, despite using the latest update, 
most of the the buttons on the main page were *completely* unresponsive. 
Zero acknowledgement of presses whatsoever. But I could tell the app 
wasn't frozen: The custom-designed text entry boxes still handled focus 
events just fine.

Tech from 1970's: Still working fine. Tech from 2010's: Pfffbbttt!!!

Clearly something's gone horribly, horribly wrong with modern software 
development.
Sep 01 2018
parent reply Gambler <fake feather.org.ru> writes:
On 9/1/2018 11:42 PM, Nick Sabalausky (Abscissa) wrote:

 On 09/01/2018 05:06 PM, Ola Fosheim Grøstad wrote:

 If you have a specific context (like banking) then you can develop a
 software method that specifies how to build banking software, and
 repeat it, assuming that the banks you develop the method for are similar

 Of course, banking has changed quite a lot over the past 15 years
 (online + mobile). Software often operates in contexts that are
 critically different and that change in somewhat unpredictable manners.


 
 Speaking of, that always really gets me:
 
 The average ATM is 24/7. Sure, there may be some downtime, but what, how
 much? For the most part, these things were more or less reliable decades
 ago, from a time with *considerably* less of the "best practices" and
 accumulated experience, know-how, and tooling we have today. And over
 the years, they still don't seem to have screwed ATMs up too badly.
 
 But contrast that to my bank's phone "app": This thing *is* rooted
 firmly in modern technology, modern experience, modern collective
 knowledge, modern hardware and...The servers it relies on *regularly* go
 down for several hours at a time during the night. That's been going on
 for the entire 2.5 years I've been using it.
 
 And for about an hour the other day, despite using the latest update,
 most of the the buttons on the main page were *completely* unresponsive.
 Zero acknowledgement of presses whatsoever. But I could tell the app
 wasn't frozen: The custom-designed text entry boxes still handled focus
 events just fine.
 
 Tech from 1970's: Still working fine. Tech from 2010's: Pfffbbttt!!!
 
 Clearly something's gone horribly, horribly wrong with modern software
 development.


I wouldn't vouch for ATM reliability. You would be surprised what kinds
of garbage software they run. Think Windows XP for OS:

http://info.rippleshot.com/blog/windows-xp-still-running-95-percent-atms-world

But in general, I believe the statement about comparative reliability of
tech from 1970s is true. I'm perpetually impressed with is all the
mainframe software that often runs mission-critical operations in places
you would least expect.

Telecom systems are generally very reliable, although it feels that
started to change recently.
Sep 02 2018
parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 09/02/2018 07:17 PM, Gambler wrote:

 
 But in general, I believe the statement about comparative reliability of
 tech from 1970s is true. I'm perpetually impressed with is all the
 mainframe software that often runs mission-critical operations in places
 you would least expect.


I suspect it may be because, up until around the 90's, in order to get 
any code successfully running on the computer at all, you pretty much 
had to know at least a thing or two about how a computer works and how 
to use it. And performance/efficiency issues were REALLY obvious. Not to 
mention the institutional barriers to entry: Everyone didn't just have a 
computer in their pocket, or even in their den at home.

(Plus the machines themselves tended to be simpler: It's easier to write 
good code when a single programmer can fully understand every byte of 
the machine and their code is all that's running.)

In the 50's/60's in particular, I imagine a much larger percentage of 
programmers probably had either some formal engineering background or 
something equally strong.

But now, pretty much anyone can (and often will) cobble together 
something that more-or-less runs. Ie, there used to be a stronger 
barrier to entry, and the machines/tools tended to be less tolerant of 
problems.
Sep 02 2018
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 3 September 2018 at 02:58:01 UTC, Nick Sabalausky 
(Abscissa) wrote:

 In the 50's/60's in particular, I imagine a much larger 
 percentage of programmers probably had either some formal 
 engineering background or something equally strong.


I guess some had, but my impression it that it was a rather mixed 
group (probably quite a few from physics since they got to use 
computers for calculations).

I have heard that some hired people with a music background as 
musicians understood the basic algorithmic ideas of instructions 
and loops. I.e. how to read and write instructions to be followed 
(sheet-music).

Programming by punching in numbers was pretty tedious too... so 
you would want someone veeeery patient.
Sep 04 2018
prev sibling parent Kagamin <spam here.lot> writes:
On Saturday, 1 September 2018 at 11:32:32 UTC, Jonathan M Davis 
wrote:

 I think that his point was more that it's sometimes argued that 
 software engineering really isn't engineering in the classical 
 sense. If you're talking about someone like a civil engineer 
 for instance, the engineer applies well-known and established 
 principles to everything they do in a disciplined way.


If they are asked to do so. In an attempt to be fancy, the sewage 
system in my apartment doesn't have a hydraulic seal, but has a 
workaround: one pipe is flexible. How physical is that?


 The engineering aspects of civil engineering aren't subjective 
 at all. They're completely based in the physical sciences. 
 Software engineering on the other hand isn't based on the 
 physical sciences at all, and there really isn't general 
 agreement on what good software engineering principles are.


Like in science, ones based on previous experience.


 https://en.wikipedia.org/wiki/Software_engineering
 One of the core issues in software engineering is that its 
 approaches are not empirical enough because a real-world 
 validation of approaches is usually absent


That criticism isn't very informed. Also is the problem really in 
how it's called?


 Issues with management cause other problems on top of all of 
 that, but even if you have a group of software engineers doing 
 their absolute best to follow good software engineering 
 principles without any kind of management interference, what 
 they're doing is still very different from most engineering 
 disciplines


Because hardware engineers want to pass certification. Never 
heard of what they do when they are not constrained by that? And 
even then there's a lot of funny stuff that passes certification 
like that x-ray machine and Intel processors.


 and it likely wouldn't be hard for another group of competent 
 software engineers to make solid arguments about why the good 
 software engineering practices that they're following actually 
 aren't all that good.


Anything created by humans has flaws and can be criticized.
Sep 03 2018
prev sibling parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 08/31/2018 05:09 PM, H. S. Teoh wrote:

 
 It's precisely for this reason that the title "software engineer" makes
 me cringe on the one hand, and snicker on the other hand.  I honestly
 cannot keep a straight face when using the word "engineering" to
 describe what a typical programmer does in the industry these days.
 


Science is the reverse-engineering of reality to understand how it 
works. Engineering is the practical application of scientific knowledge.

I don't know, maybe those are simplified, naive definitions. But I've 
long been of the opinion that programming is engineering...*if* and only 
if...you're doing it right.

Of course, my background is primarily from programming itself, not from 
an existing engineering field, so I certainly won't claim that what I do 
necessarily qualifies as "engineering", but it is something I try to 
aspire to, FWIW.
Sep 01 2018
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/31/2018 1:42 PM, Paulo Pinto wrote:

 Some countries do have engineering certifications and professional permits for 
 software engineering, but its still a minority.


That won't fix anything, because there is NO conventional wisdom in software 
engineering for how to deal with program bugs. I suspect I am the first to try 
to apply principles from aerospace to general engineering (including software).

For example, in any CS program, are there any courses at all about this?
Aug 31 2018
next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, August 31, 2018 4:23:09 PM MDT Walter Bright via Digitalmars-d 
wrote:

 On 8/31/2018 1:42 PM, Paulo Pinto wrote:

 Some countries do have engineering certifications and professional
 permits for software engineering, but its still a minority.


 That won't fix anything, because there is NO conventional wisdom in
 software engineering for how to deal with program bugs. I suspect I am
 the first to try to apply principles from aerospace to general
 engineering (including software).

 For example, in any CS program, are there any courses at all about this?


There are probably some somewhere, but most CS programs really aren't about
writing good software or even being a software engineer. Some definitely try
to bring some focus on that, but it's far, far more common that the focus is
on computer science concepts and not on software engineering. A good CS
program gives you a lot of theory, but they're rarely big on the practical
side of things. I think that it's a rarity for programmers to graduate
college with a good understanding of how to be a good software engineer in
the field. That's the sort of thing that they're much more likely to learn
on the job, and plenty of jobs don't do a good job with it. Motivated
programmers can certainly find resources for learning good software
engineering skills and/or find mentors who can help them learn them - and
many programmers do - but it's _very_ easy to learn enough programming to
get a job and get by without being very good at it. And if a programmer
isn't really motivated to improve themselves, it's highly unlikely that
they're going to have good software engineering skills. It's often pretty
scary how poor the average programer is, and in my experience, when trying
to hire someone, you can end up going through a lot of really bad candidates
before finding someone even passable let alone good.

- Jonathan M Davis
Aug 31 2018
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Aug 31, 2018 at 04:45:57PM -0600, Jonathan M Davis via Digitalmars-d
wrote:

 On Friday, August 31, 2018 4:23:09 PM MDT Walter Bright via Digitalmars-d 
 wrote:


[...]

 That won't fix anything, because there is NO conventional wisdom in
 software engineering for how to deal with program bugs. I suspect I
 am the first to try to apply principles from aerospace to general
 engineering (including software).

 For example, in any CS program, are there any courses at all about
 this?


 
 There are probably some somewhere, but most CS programs really aren't
 about writing good software or even being a software engineer. Some
 definitely try to bring some focus on that, but it's far, far more
 common that the focus is on computer science concepts and not on
 software engineering. A good CS program gives you a lot of theory, but
 they're rarely big on the practical side of things.


[...]

 It's often pretty scary how poor the average programer is, and in my
 experience, when trying to hire someone, you can end up going through
 a lot of really bad candidates before finding someone even passable
 let alone good.


[...]

The problem is that there is a disconnect between academia and the
industry.

The goal in academia is to produce new research, to find ground-breaking
new theories that bring a lot of recognition and fame to the institution
when published. It's the research that will bring in the grants and
enable the institution to continue existing. As a result, there is heavy
focus on the theoretical concepts, which are the basis for further
research, rather than pragmatic tedium like how to debug a program.

The goal in the industry is to produce working software. The industry
doesn't really care if you discovered an amazing new way of thinking
about software; they want to actually produce software that can be
shipped to the customer, even if it isn't using the latest and greatest
theoretical concepts.  So they don't really care how good a grasp you
have on computability theory, but they *do* care a lot that you know how
to debug a program so that it can be shipped on time. (They don't care
*how* you debug the program, just that you know how to to it, and do it
efficiently.)

A consequence of this disconnect is that the incentives are set up all
wrong.  Professors are paid to publish research papers, not to teach
students.  Teaching is often viewed as an undesired additional burden
you're obligated to carry out, a chore that you just want to get over
with in the fastest, easiest possible way, so that you can go back to
doing research.  After all, it's the research that will win you the
grants, not the fact that you won teaching awards 3 years in a row, or
that your students wrote a glowing review of your lectures. So the
quality of teaching already suffers.

Then the course material itself is geared toward producing more
researchers, rather than industry workers.  After all, the institution
needs to replace aging and retiring faculty members in order to continue
existing.  To do that, it needs to produce students who can become
future researchers.  And since research depends on theory, theory is
emphasized, and pragmatism like debugging skills aren't really relevant.

On the other side of the disconnect, the industry expects that students
graduating from prestigious CS programs ought to know how to program.
The hiring manager sees a degree from MIT or Stanford and is immediately
impressed; but he doesn't have the technical expertise to realize what
that degree actually means: that the student excelled in the primarily
theory-focused program, which may or may not translate to practical
skills like programming and debugging ability that would make them
productive in the industry.  All the hiring manager knows is that
institution Y is renowned for their CS program, and therefore he gives
more weight to candidates who hold a degree from Y, even if that
actually doesn't guarantee that the candidate will be a good programmer.
As a result, the software department is filled up with people who are
good at theory, but whose practical programming skills can range
anywhere from passably good to practically non-existent.  And now these
people with wide-ranging programming abilities have to work together as
a team.

Is it any wonder at all that the quality of the resulting software is so
bad?


T

-- 
Amateurs built the Ark; professionals built the Titanic.
Aug 31 2018
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
Then there are polytechnics which I went to for my degree, where the 
focus was squarely on Industry and not on academia at all.

But in saying that, we had third year students starting out not 
understanding how cli arguments work so...

Proper software engineering really takes 5+ years just to get started, 
10+ to become actually good at it. Sadly that won't be acceptable in our 
current society.
Aug 31 2018
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 1 September 2018 at 05:51:10 UTC, rikki cattermole 
wrote:

 Then there are polytechnics which I went to for my degree, 
 where the focus was squarely on Industry and not on academia at 
 all.


But the teaching is based on research in a good engineering 
school...


 But in saying that, we had third year students starting out not 
 understanding how cli arguments work so...

 Proper software engineering really takes 5+ years just to get 
 started, 10+ to become actually good at it. Sadly that won't be 
 acceptable in our current society.


The root cause of bad software is that many programmers don't 
even have an education in CS or software engineering, or didn't 
do a good job while getting it!

Another problem is that departments get funding based on how many 
students they have and many students are not fit to be 
programmers. Then you have the recruitment process and people in 
management without a proper theoretical understanding of the 
topic looking for "practical programmers" (must have experience 
with framework X) which basically means that they get programmers 
with low theoretical understanding and therefore fail to build an 
environment where people can learn... So building a good team 
where people can become experts (based on actual research) is 
mostly not happening. It becomes experience based and the 
experience is that it isn't broken if customers are willing to 
pay.

Basic capitalism. Happens outside programming too. Make 
good-looking shit that breaks after the warranty is void.

Anyway, Software Engineering most certainly is a research 
discipline separate from CS and there is research and theory for 
developing software at different cost levels.

Games are not bug free because that would be extremely expensive, 
and cause massive delays in shipping which makes it impossible to 
plan marketing. Games are less buggy when they reuse existing 
frameworks, but that makes for less exciting designs.
Aug 31 2018
parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 09/01/2018 02:15 AM, Ola Fosheim Grøstad wrote:

 
 The root cause of bad software is that many programmers don't even have 
 an education in CS or software engineering, or didn't do a good job 
 while getting it!
 


Meh, no. The root cause trifecta is:

A. People not caring enough about their own craft to actually TRY to 
learn how to do it right.

B. HR people who know nothing about the domain they're hiring for.

C. Overall societal reliance on schooling systems that:

     - Know little about teaching and learning,

     - Even less about software development,

     - And can't even decide whether their priorities should be "pure 
theory *without* sufficient practical" or "catering to the 
above-mentioned HR folk's swing-and-miss, armchair-expert attempts at 
defining criteria for identifying good programmers" (Hint: The answer is 
"neither").
Sep 01 2018
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 2 September 2018 at 04:59:49 UTC, Nick Sabalausky 
(Abscissa) wrote:

 A. People not caring enough about their own craft to actually 
 TRY to learn how to do it right.


Well, that is an issue. That many students enroll into 
programming courses, not because they take pride in writing good 
programs, but because they think that working with computers 
would somehow be an attractive career path.

Still, my impression is that students that write good programs 
also seem to be good at theory.


 B. HR people who know nothing about the domain they're hiring 
 for.


Well,  I think that goes beyond HR people. Also lead programmers 
in small businesses that either don't have an education or didn't 
do too well, will feel that someone that does know what they are 
doing is a threat to their position. Another issue is that 
management does not want to hire people who they think will get 
bored with their "boring" software projects... So they rather 
hire someone less apt that will not quit the job after 6 months...

So there are a lot of dysfunctional aspects at the very 
foundation of software development processes in many real world 
businesses.

I wouldn't expect anything great to come out of this... I also 
suspect that many managers don't truly understand that one good 
programmer can replace several bad ones...


 C. Overall societal reliance on schooling systems that:

     - Know little about teaching and learning,

     - Even less about software development,


Not sure what you mean by this. In many universities you can sign 
up for the courses you are interested in. It is really up to the 
student to figure out what their profile should be.

Anyway, since there are many methodologies, you will have to 
train your own team in your specific setup. With a well rounded 
education a good student should have the knowledge that will let 
them participate in discussions about how to structure the work.

So there is really no way for any university to teach you exactly 
what the process should be like.

This is no different from other fields.  Take a sawmill; there 
are many ways to structure the manufacturing process in a 
sawmill. Hopefully people with an education is able to grok the 
process and participate in discussions about how to improve it, 
but the specifics is dependent on the concrete sawmill production 
line.
Sep 02 2018
prev sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 09/01/2018 01:51 AM, rikki cattermole wrote:

 
 But in saying that, we had third year students starting out not 
 understanding how cli arguments work so...
 


How I wish that sort of thing surprised me ;)

As part of the generation that grew up with BASIC on 80's home 
computers, part of my spare time in high school involved some PalmOS 
development (man I miss PalmOS). Wasn't exactly anything special - you 
pony up a little $ for Watcom (or was it Borland?), open the IDE, follow 
the docs, do everything you normally do. Read a book. Yawn. After that, 
in college, had a job working on Palm and WAP websites (anyone remember 
those? Bonus points if you remember the Palm version - without WiFi or 
telephony it was an interesting semi-mobile experience).

Imagine my shock another year after that when I saw the college I was 
attending bragging how their computer science *graduate* students...with 
the help and guidance of a professor...had gotten a hello world "running 
on an actual Palm Pilot!" Wow! Can your grad students also tie their own 
shoes and wipe their own noses with nothing more than their own wits and 
somebody else to help them do it??? Because, gee golly, that would be 
one swell accomplishment! Wow! Hold your hat, Mr. Dean, because Ivy 
League, here you come!!
Sep 01 2018
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Saturday, September 1, 2018 10:44:57 PM MDT Nick Sabalausky (Abscissa) 
via Digitalmars-d wrote:

 On 09/01/2018 01:51 AM, rikki cattermole wrote:

 But in saying that, we had third year students starting out not
 understanding how cli arguments work so...


 How I wish that sort of thing surprised me ;)

 As part of the generation that grew up with BASIC on 80's home
 computers, part of my spare time in high school involved some PalmOS
 development (man I miss PalmOS). Wasn't exactly anything special - you
 pony up a little $ for Watcom (or was it Borland?), open the IDE, follow
 the docs, do everything you normally do. Read a book. Yawn. After that,
 in college, had a job working on Palm and WAP websites (anyone remember
 those? Bonus points if you remember the Palm version - without WiFi or
 telephony it was an interesting semi-mobile experience).

 Imagine my shock another year after that when I saw the college I was
 attending bragging how their computer science *graduate* students...with
 the help and guidance of a professor...had gotten a hello world "running
 on an actual Palm Pilot!" Wow! Can your grad students also tie their own
 shoes and wipe their own noses with nothing more than their own wits and
 somebody else to help them do it??? Because, gee golly, that would be
 one swell accomplishment! Wow! Hold your hat, Mr. Dean, because Ivy
 League, here you come!!


Ouch. Seriously, seriously ouch.

- Jonathan M Davis
Sep 01 2018
parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 09/02/2018 12:53 AM, Jonathan M Davis wrote:

 
 Ouch. Seriously, seriously ouch.
 


Heh, yea, well...that particular one was state party school, so, what 
y'gonna do? *shrug*

Smug as I may have been at the at the time, it wasn't until later I 
realized the REAL smart ones were the ones out partying, not the grads 
or the nerds like me. Ah, young hubris ;)  (Oh, the computer art 
students, BTW, were actually really fun to hang out with! I think they 
probably managed to hit the best balance of work & play.)
Sep 01 2018
parent reply Joakim <dlang joakim.fea.st> writes:
On Sunday, 2 September 2018 at 05:16:43 UTC, Nick Sabalausky 
(Abscissa) wrote:

 On 09/02/2018 12:53 AM, Jonathan M Davis wrote:

 
 Ouch. Seriously, seriously ouch.
 


 Heh, yea, well...that particular one was state party school, 
 so, what y'gonna do? *shrug*

 Smug as I may have been at the at the time, it wasn't until 
 later I realized the REAL smart ones were the ones out 
 partying, not the grads or the nerds like me.


Why? Please don't tell me you believe this nonsense:

"Wadhwa... argues (I am not joking) that partying is a valuable 
part of the college experience because it teaches students 
interpersonal skills."
https://www.forbes.com/sites/jerrybowyer/2012/05/22/a-college-bubble-so-big-even-the-new-york-times-and-60-minutes-can-see-it-sort-of/
Sep 01 2018
parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 09/02/2018 02:06 AM, Joakim wrote:

 On Sunday, 2 September 2018 at 05:16:43 UTC, Nick Sabalausky (Abscissa) 
 wrote:

 Smug as I may have been at the at the time, it wasn't until later I 
 realized the REAL smart ones were the ones out partying, not the grads 
 or the nerds like me.


 
 Why? Please don't tell me you believe this nonsense:
 
 "Wadhwa... argues (I am not joking) that partying is a valuable part of 
 the college experience because it teaches students interpersonal skills."
 https://www.forbes.com/sites/jerrybowyer/2012/05/22/a-college-bubble-so-big-even-the-new-york-times-and-60-minutes
can-see-it-sort-of/ 
 


Learning skills from partying? Hah hah, no, no, it's not about anything 
like that. :) (Social skills matter, but obviously plenty of other ways 
to practice those.)

No, it's just that honing skills isn't the only thing in life that 
matters. Simply living life while you're here is important too, for its 
own sake, even if you only realize it after the fact.
Sep 02 2018
parent reply Joakim <dlang joakim.fea.st> writes:
On Sunday, 2 September 2018 at 07:56:09 UTC, Nick Sabalausky 
(Abscissa) wrote:

 On 09/02/2018 02:06 AM, Joakim wrote:

 On Sunday, 2 September 2018 at 05:16:43 UTC, Nick Sabalausky 
 (Abscissa) wrote:

 Smug as I may have been at the at the time, it wasn't until 
 later I realized the REAL smart ones were the ones out 
 partying, not the grads or the nerds like me.


 
 Why? Please don't tell me you believe this nonsense:
 
 "Wadhwa... argues (I am not joking) that partying is a 
 valuable part of the college experience because it teaches 
 students interpersonal skills."
 https://www.forbes.com/sites/jerrybowyer/2012/05/22/a-college-bubble-so-big-even-the-new-york-times-and-60-minutes-can-see-it-sort-of/
 


 Learning skills from partying? Hah hah, no, no, it's not about 
 anything like that. :) (Social skills matter, but obviously 
 plenty of other ways to practice those.)

 No, it's just that honing skills isn't the only thing in life 
 that matters. Simply living life while you're here is important 
 too, for its own sake, even if you only realize it after the 
 fact.


Eh, having fun should be part of the college experience of 
course, but I suspect most of those out partying were taking it 
far beyond that. I bet many of them regret that today.

You're right that college is largely an irrelevant playground, 
precisely because of the incoherent combination of theory and 
bows to what they think are popular industry practices that you 
laid out. Most will be out of business within a decade or two, as 
online learning takes their place.
Sep 02 2018
parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 09/02/2018 05:43 AM, Joakim wrote:

 Most will be out 
 of business within a decade or two, as online learning takes their place.


I kinda wish I could agree with that, but schools are too much of a 
sacred cow to be going anywhere anytime soon. And for that matter, the 
online ones still have to tackle many of the same challenges anyway, WRT 
successful and effective teaching.

Really the only difference is "physical classroom vs no physical 
classroom". Well, that and maybe price, but the community colleges have 
had the uni's well beat on price for a long time (even manage to do a 
good job teaching certain things, depending on the instructor), but they 
haven't made the uni's budge: The best they've been able to do is 
establish themselves as a supplement to the uni's, where people start 
out with some of their gen-ed classes at the (comparatively) cheap 
community colleges for the specific purpose of later transferring to a uni.
Sep 02 2018
parent reply Joakim <dlang joakim.fea.st> writes:
On Sunday, 2 September 2018 at 19:30:58 UTC, Nick Sabalausky 
(Abscissa) wrote:

 On 09/02/2018 05:43 AM, Joakim wrote:

 Most will be out of business within a decade or two, as online 
 learning takes their place.


 I kinda wish I could agree with that, but schools are too much 
 of a sacred cow to be going anywhere anytime soon. And for that 
 matter, the online ones still have to tackle many of the same 
 challenges anyway, WRT successful and effective teaching.

 Really the only difference is "physical classroom vs no 
 physical classroom". Well, that and maybe price, but the 
 community colleges have had the uni's well beat on price for a 
 long time (even manage to do a good job teaching certain 
 things, depending on the instructor), but they haven't made the 
 uni's budge: The best they've been able to do is establish 
 themselves as a supplement to the uni's, where people start out 
 with some of their gen-ed classes at the (comparatively) cheap 
 community colleges for the specific purpose of later 
 transferring to a uni.


That's because what the current online efforts do is simply slap 
the in-class curricula online, whereas what really needs to be 
done is completely change what's taught, away from the incoherent 
mix of theory and Java that basically describes every degree 
(non-CS too), and how it's tested and certified. When that 
happens, the unis will collapse, because online learning will be 
so much better at a fraction of the cost.

As for sacred cows, the newspaper business was one of them, ie 
Journalism, but it's on death's door, as I pointed out in this 
forum years ago:

https://en.m.wikipedia.org/wiki/File:Naa_newspaper_ad_revenue.svg

There are a lot of sacred cows getting butchered by the internet, 
college will be one of the easier ones to get rid of.

On Sunday, 2 September 2018 at 21:07:20 UTC, Nick Sabalausky 
(Abscissa) wrote:

 On 09/01/2018 03:47 PM, Everlast wrote:

 
 It's because programming is done completely wrong. All we do 
 is program like it's 1952 all wrapped up in a nice box and bow 
 tie. WE should have tools and a compiler design that all work 
 interconnected with complete graphical interfaces that aren't 
 based in the text gui world(an IDE is just a fancy text 
 editor). I'm talking about 3D code representation using 
 graphics so projects can be navigated  visually in a dynamic 
 way and many other things.


 There are really two main, but largely independent, aspects to 
 what you're describing: Visual representation, and physical 
 interface:

 A. Visual representation:
 -------------------------

 By visual representation, I mean "some kind of text, or UML-ish 
 diagrams, or 3D environment, etc".

 What's important to keep in mind here is: The *fundamental 
 concepts* involved in programming are inherently abstract, and 
 thus equally applicable to whatever visual representation is 
 used.

 If you're going to make a diagram-based or VR-based programming 
 tool, it will still be using the same fundamental concepts that 
 are already established in text-based programming: Imperative 
 loops, conditionals and variables. Functional/declarative 
 immutability, purity and high-order funcs. Encapsulation. 
 Pipelines (like ranges). Etc. And indeed, all GUI based 
 programming tools have worked this way. Because how *else* are 
 they going to work?

 If what you're really looking for is something that replaces or 
 transcends all of those existing, fundamental programming 
 concepts, then what you're *really* looking for is a new 
 fundamental programming concept, not a visual representation. 
 And ance you DO invent a new fundamental programming concept, 
 being abstract, it will again be applicable to a variety of 
 possible visual representations.

 That said, it is true some concepts may be more readily 
 amenable to certain visual representations than others. But, at 
 least for all the currently-known concepts, any combination of 
 concept and representation can certainly be made to work.

 B. Physical interface:
 ----------------------

 By this I mean both actual input devices (keyboards, 
 controllers, pointing devices) and also the mappings from their 
 affordances (ie, what you can do with them: push button x, tilt 
 stick's axis Y, point, move, rotate...) to specific actions 
 taken on the visual representation (navigate, modify, etc.)

 The mappings, of course, tend to be highly dependant on the 
 visual representation (although, theoretically, they don't 
 strictly HAVE to be). The devices themselves, less so: For 
 example, many of us use a pointing device to help us navigate 
 text. Meanwhile, 3D modelers/animators find it's MUCH more 
 efficient to deal with their 3D models and environments by 
 including heavy use of the keyboard in their workflow instead 
 of *just* a mouse and/or wacom alone.

 An important point here, is that using a keyboard has a 
 tendency to be much more efficient for a much wider range of 
 interactions than, say, a pointing device, like a mouse or 
 touchscreen. There are some things a mouse or touchscreen is 
 better at (ie, pointing and learning curve), but even on a 
 touchscreen, pointing takes more time than pushing a button and 
 is somewhat less composable with additional actions than, 
 again, pushing/holding a key on a keyboard.

 This means that while pointing, and indeed, direct manipulation 
 in general, can be very beneficial in an interface, placing too 
 much reliance on it will actually make the user LESS productive.

 The result:
 -----------

 For programming to transcend the current text/language model, 
 *without* harming either productivity or programming power (as 
 all attempts so far have done), we will first need to invent 
 entirely new high-level concepts which are simultaneously both 
 simple/high-level enough AND powerful enough to obsolete most 
 of the nitty-gritty lower-level concepts we programmers still 
 need to deal with on a regular basis.

 And once we do that, those new super-programming concepts 
 (being the abstract concepts that they inherently are) will 
 still be independent of visual representation. They might 
 finally be sufficiently powerful AND simple that they *CAN* be 
 used productively with graphical non-text-language 
 representation...but they still will not *require* such a 
 graphical representation.

 That's why programming is still "stuck" in last century's 
 text-based model: Because it's not actually stuck: It still has 
 significant deal-winning benefits over newer developments. And 
 that's because, even when "newer" does provide improvements, 
 newer still isn't *inherently* superior on *all* counts. That's 
 a fact of life that is easily, and frequently, forgotten in 
 fast-moving domains.


Ironically, you're taking a way too theoretical approach to this. 
;) Simply think of the basic advances a graphical debugger like 
the one in Visual Studio provides and advance that out several 
levels.

For example, one visualization I was talking about on IRC a 
decade ago and which I still haven't seen anybody doing, though I 
haven't really searched for it, is to have a high-level graphical 
visualization of the data flowing through a program. Just as 
dmd/ldc generate timing profile data for D functions by 
instrumenting the function call timings, you could instrument the 
function parameter data too (you're not using globals much, 
right? ;) ) and then record and save the data stream generated by 
some acceptance testing. Then, you periodically run those 
automated acceptance tests and look at the data stream 
differences as a color-coded flow visualization through the 
functions, with the data that stays the same shown as green, 
whereas the data that changed between different versions of the 
software as red. Think of something like a buildbot console, but 
where you could zoom in on different colors till you see the 
actual data stream:

https://ci.chromium.org/p/chromium/g/main/console

You'd then verify that the data differences are what you intend- 
for example, if you refactored a function to change what 
parameters it accepts, the data differences for the same external 
user input may be valid- and either accept the new data stream as 
the baseline or make changes till it's okay. If you refactor your 
code a lot, you could waste time with a lot of useless churn, but 
that's the same problem unit or other tests have with refactoring.

This high-level approach would benefit most average software much 
more than unit testing, as you usually don't care about 
individidual components or hitting all their edge cases. That's 
why most software doesn't use unit tests in the first place.

Note that I'm not saying unit tests are not worthwhile, 
particularly for libraries, only that realistically it'd be 
easier to get programmers to use this high-level view I'm 
outlining than writing a ton of unit tests, much less effort too. 
Ideally, you do both and they complement each other, along with 
integration testing and the rest.

In other words, we don't have to get rid of text representations 
altogether: there's a lot of scope for much better graphical 
visualizations of the textual data or code we're using now. You 
could do everything I just described by modifying the compiler to 
instrument your functions, dumping log files, and running them 
through diff, but that's the kind of low-level approach we're 
stuck with now. Ideally, we'd realize that _certain workflows are 
so common that we need good graphical interfaces for them_ and 
standardize on those, but I think Everlast's point is that's 
happening much slower than it should, which I agree with.

On Sunday, 2 September 2018 at 21:19:38 UTC, Ola Fosheim Grøstad 
wrote:

 So there are a lot of dysfunctional aspects at the very 
 foundation of software development processes in many real world 
 businesses.

 I wouldn't expect anything great to come out of this...


One of the root causes of that dysfunction is there's way too 
much software written. Open source has actually helped alleviate 
this, because instead of every embedded or server developer who 
needs an OS kernel convincing management that they should write 
their own, they now have a hard time justifying it when a free, 
OSS kernel like linux is out there, which is why so many of those 
places use linux now. Of course, you'd often like to modify the 
kernel and linux may not be stripped down or modular enough for 
some, but there's always other OSS kernels like Minix or Contiki 
for them.

Software is still in the early stages like the automative 
industry in the US, when there were hundreds of car 
manufacturers, most of them producing as low-quality product as 
software companies now:

https://en.m.wikipedia.org/wiki/Automotive_industry_in_the_United_States

Rather than whittling down to three large manufacturers like the 
US car industry did, open source provides a way for thousands of 
software outfits, individual devs even, to work on commonly used 
code as open source, while still being able to specialize when 
needed, particularly with permissive licenses. So, much of that 
dysfunction will be solved by consolidation, but a completely 
different kind of consolidation than was done for cars, because 
software is completely different than physical goods.
Sep 03 2018
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 03/09/2018 7:05 PM, Joakim wrote:

 One of the root causes of that dysfunction is there's way too much 
 software written. Open source has actually helped alleviate this, 
 because instead of every embedded or server developer who needs an OS 
 kernel convincing management that they should write their own, they now 
 have a hard time justifying it when a free, OSS kernel like linux is out 
 there, which is why so many of those places use linux now. Of course, 
 you'd often like to modify the kernel and linux may not be stripped down 
 or modular enough for some, but there's always other OSS kernels like 
 Minix or Contiki for them.


Yes but 30 years ago it was actually realistic and even best practice to 
write your own OS as part of deployment of e.g. game. Can't say that now 
even in the micro controller space.
Sep 03 2018
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 31 August 2018 at 23:20:08 UTC, H. S. Teoh wrote:

 The problem is that there is a disconnect between academia and 
 the industry.


No, there isn't. Plenty of research is focused on software 
engineering and software process improvement. Those are separate 
research branches.

The problem is that most people in forums don't have a basic 
grasp of how improbable it is for complex systems to be bug free.

After taking a course where you formally prove a program to be 
bug free fix that problem real fast.

Also, asserts doesn't prevent bugs, they can trip hours or days 
after the problem arose. The problem doesn't have to be the code 
either, it could be the data-structure, how different systems 
interact etc. So, just running the buggy software is problematic, 
even before the assert trips. (E.g. your plane could be in flames 
before the assert trips.)

Also, having a shutdown because a search function sometimes 
return the wrong result is just as unacceptable as getting late 
to work because you couldn't drive your car because it "was 
asserted" that the clutch was not in perfect condition.


 The goal in academia is to produce new research, to find 
 ground-breaking new theories that bring a lot of recognition


Most research does not focus on ground-breaking theories, but 
marginal improvments on existing knowledge.

  > continue existing. As a result, there is heavy focus on the

 theoretical concepts, which are the basis for further research, 
 rather than pragmatic tedium like how to debug a program.


All formalized knowledge that is reusable is theory. Everything 
you can learn from books is based on theory, unless you only read 
stories and distill knowledge from them with no help from the 
author.

There are of course people who build theory on how to structure, 
test and debug programs.


 The goal in the industry is to produce working software.


NO, the goal is to make MONEY. If that means shipping bad 
software and getting to charge large amounts of money for 
consulting then that is what the industry will go for.



 using the latest and greatest theoretical concepts.  So they 
 don't really care how good a grasp you have on computability 
 theory, but they *do* care a lot that you know how to debug a 
 program so that it can be shipped on time. (They don't care 
 *how* you debug the program, just that you know how to to it, 
 and do it efficiently.)


They don't care if it works well, they don't care if it is slow 
and buggy, they care about how the people who pay for it 
respond...


 A consequence of this disconnect is that the incentives are set 
 up all wrong.


Yes, money does not produce quality products, unless the majority 
of customers are knowledgable and demanding.


 Professors are paid to publish research papers, not to teach 
 students.


I think people publish most when they try to become professors. 
After getting there the main task is to teach others the topic 
and help others to do research (e.g. supervising).

  > research.  After all, it's the research that will win you the

 grants, not the fact that you won teaching awards 3 years in a 
 row, or that your students wrote a glowing review of your 
 lectures. So the quality of teaching already suffers.


The have a salary, they don't need a grant for themselves. They 
need a grant to get a salary to fund ph.d. students. E.g. they 
need grants to teach how to do research.


 Then the course material itself is geared toward producing more 
 researchers, rather than industry workers.


Most of them become industry workers...


 Is it any wonder at all that the quality of the resulting 
 software is so bad?


The current shipping software is much better than the software 
that was shipped in the 80s and 90s. To a large extent thanks to 
more and more software being developed in high level languages 
using well tested libraries and frameworks (not C, C++ etc).

Most cars on the road are somewhat buggy, and they could crash as 
a result of those bugs. Most programs are somewhat buggy, and 
they could crash as a result of those bugs.

Most of the buggy air fighters are on the ground, but would you 
want you car to be unusable 20% of the time?

Would you want Google to disappear 20% of the time because the 
ranking of search results is worse than what the spec says it 
should be?

As usual, these discussions aren't really based on a good 
theoretical understanding of what a bug is.

Try to prove one of your programs formally correct, then you'll 
realize that it is unattainable for most useful programs that 
retain state.

The human body is full of bugs. Hell, we rely on them, even on 
the cell-level. We need those parasites to exist. As programs get 
larger you need to focus on a different strategy to get a 
reliable system. (E.g. actor based thinking).
Aug 31 2018
prev sibling parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 08/31/2018 07:20 PM, H. S. Teoh wrote:

 
 The problem is that there is a disconnect between academia and the
 industry.
 
 The goal in academia is to produce new research, to find ground-breaking
 new theories that bring a lot of recognition and fame to the institution
 when published. It's the research that will bring in the grants and
 enable the institution to continue existing. As a result, there is heavy
 focus on the theoretical concepts, which are the basis for further
 research, rather than pragmatic tedium like how to debug a program.
 


I don't know where you've been but it doesn't match anything I've ever seen.

Everything I've ever seen: The goal in academia is to advertise 
impressive-looking rates for graduation and job placement. This 
maximizes the size of the application pool which, depending on the 
school, means one of two things:

1. More students paying ungodly tuition rates. Thus making the schools 
and their administrators even richer. (Pretty much any public liberal 
arts school.)

or

2. Higher quality students (defined by the school as "more likely to 
graduate and more likely to be placed directly in a job"), thus earning 
the school the right to demand an even MORE ungodly tuition from the 
fixed-size pool of students they accept. Thus making the schools and 
their administrators even richer. (Pretty much any private liberal arts 
school.)

Achieving the coveted prize of "We look attractive to applicants" involves:

First: As much of a revolving-door system as they can get away with 
without jeopardizing their accreditation.

And secondly: Supplementing the basic Computer Science theory with 
awkward, stumbling, half-informed attempts at placating the industry's 
brain-dead, know-nothing HR monkeys[1] with the latest hot trends. For 
me, at the time, that meant Java 2 and the "Thou must OOP, for OOP is 
all" religion.

[1] "I don't know anything about programming, but I'm good at 
recognizing people who are good at it."  <-- A real quote from a real HR 
monkey I once made the mistake of attempting basic communication with.

But then, let's not forget that schools have HR, too. Which leads to 
really fun teachers like the professor I had for a Computer Networking 
class:

He had a PhD in Computer Science. He would openly admit that C was the 
only language he knew. Ok, fair enough so far. But...upon my explaining 
to him how he made a mistake grading my program, I found *myself* forced 
to teach the *Computer Science professor* how strings 
(remember...C...null-terminated) worked in the *only* language he knew. 
He had NO freaking clue! A freakin' CS PhD! Forget "theory vs practical" 
- if you do not know the *fundamental basics* of EVEN ONE language, then 
you *CANNOT* function in even the theoretical or research realms, or 
teach it. Computer science doesn't even *exist* without computer 
programming! Oh, and this, BTW, was a school that pretty much any 
Clevelander will tell you "Oh! Yea, that's a really good school, it has 
a fantastic reputation!" Compared to what? Ohio State Football University?
Sep 01 2018
prev sibling next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Friday, 31 August 2018 at 22:23:09 UTC, Walter Bright wrote:

 On 8/31/2018 1:42 PM, Paulo Pinto wrote:

 Some countries do have engineering certifications and 
 professional permits for software engineering, but its still a 
 minority.


 That won't fix anything, because there is NO conventional 
 wisdom in software engineering for how to deal with program 
 bugs. I suspect I am the first to try to apply principles from 
 aerospace to general engineering (including software).

 For example, in any CS program, are there any courses at all 
 about this?


Yes, we had them on my degree, given that Portugal is one of 
those countries with engineering certifications for software 
engineering.

Certified degrees must comply with an expected level of quality, 
otherwise they aren't legally allowed to call themselves 
engineering degrees in informatics.

Now, what we don't have is the requirement of professional permit 
for everyone, unless one wants to make use of the title in public 
events or has the legal responsibility to sign off projects.

I expect other countries with engineering colleges to have 
similar situations.

--
Paulo
Aug 31 2018
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/31/2018 11:59 PM, Paulo Pinto wrote:

 For example, in any CS program, are there any courses at all about this?


 Yes, we had them on my degree,


I'm curious how the courses you took compared with the articles I wrote about
it.
Sep 01 2018
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Saturday, 1 September 2018 at 08:19:49 UTC, Walter Bright 
wrote:

 On 8/31/2018 11:59 PM, Paulo Pinto wrote:

 For example, in any CS program, are there any courses at all 
 about this?


 Yes, we had them on my degree,


 I'm curious how the courses you took compared with the articles 
 I wrote about it.


I will read the articles later, but as overview, we learned about:

- requirements gathering
- architecture design based on several methodologies, back then 
it was Booch, ER, Coad and the newly introduced UML
- introduction to way to manage source control, rcs and cvs
- design by contract, via Eiffel
- use of abstract data types as means to achieve clean 
architectures with separation of concerns
- ways to perform testing, way before unit testing was even a 
thing
- we had a semester project going from requirements gathering, 
design and implementation that was validated how well it achieved 
those goals.

Which on my year it was the implementation of subway ticketing 
system with automatic control of access doors, just the software 
part. The sensors and door controls were simulated.

And the implementation of a general purpose B+ tree library, 
another semester long project, whose integration tests where not 
available to us.

We had one week time to make our library could link and 
successfully execute all the tests that the teacher came up with 
for the acceptance testing phase. We did not have access to their 
source code, we just provided our lib.a.
Sep 01 2018
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/1/2018 2:15 AM, Paulo Pinto wrote:

 On Saturday, 1 September 2018 at 08:19:49 UTC, Walter Bright wrote:

 On 8/31/2018 11:59 PM, Paulo Pinto wrote:

 For example, in any CS program, are there any courses at all about this?


 Yes, we had them on my degree,


 I'm curious how the courses you took compared with the articles I wrote about
it.


 
 I will read the articles later, but as overview, we learned about:
 [...]


It appears to have nothing related to what the articles are about.

I'm rather sad that I've never seen these ideas outside of the aerospace 
industry. Added to that is all the pushback on them I get here, on reddit, and 
on hackernews.

I see the results all the time. Like when someone can use a radio to hack into
a 
car computer via the keyless door locks, and take over the steering and braking 
system. Even worse, when engineers discuss that, it never occurs to them that 
critical systems should be electrically separate from the infotainment system 
and anything that receives wireless data. They just talk about "fixing the bug".

BTW, people who run spy networks figured this out long ago. It's all divided up 
by "need to know" rules and cells. Any spy captured and tortured can only give 
up minimal information, not something that will allow the enemy to roll up the 
entire network.
Sep 01 2018
next sibling parent Gambler <fake feather.org.ru> writes:
On 9/1/2018 7:36 AM, Walter Bright wrote:

 On 9/1/2018 2:15 AM, Paulo Pinto wrote:

 On Saturday, 1 September 2018 at 08:19:49 UTC, Walter Bright wrote:

 On 8/31/2018 11:59 PM, Paulo Pinto wrote:

 For example, in any CS program, are there any courses at all about
 this?


 Yes, we had them on my degree,


 I'm curious how the courses you took compared with the articles I
 wrote about it.


 I will read the articles later, but as overview, we learned about:
 [...]


 It appears to have nothing related to what the articles are about.
 
 I'm rather sad that I've never seen these ideas outside of the aerospace
 industry. Added to that is all the pushback on them I get here, on
 reddit, and on hackernews.


Some people do. I should take this opportunity to plug one of Alan Kay's
great talks.

"Programming and Scaling"
https://www.youtube.com/watch?v=YyIQKBzIuBY

But Kay definitely isn't a Hacker News/Reddit darling, even though he's
well respected. He's too critical of the current state of software
engineering. Rightfully so, if you ask me.
Sep 01 2018
prev sibling parent Guillaume Piolat <spam smam.org> writes:
On Saturday, 1 September 2018 at 11:36:52 UTC, Walter Bright 
wrote:

 I'm rather sad that I've never seen these ideas outside of the 
 aerospace industry. Added to that is all the pushback on them I 
 get here, on reddit, and on hackernews.


Just chiming in to say you're certainly not ignored, it's an 
article on d-idioms 
https://p0nce.github.io/d-idioms/#Unrecoverable-vs-recoverable-errors

I tend to follow your advice and let some assertions in 
production, even for a b2c product I was surprised to see it 
works well, as it's a lot better than not having bug reports and 
stay with silent failure in the wild. None of that would happen 
with "recovered" bugs.
Sep 03 2018
prev sibling parent reply Dennis <dkorpel gmail.com> writes:
On Friday, 31 August 2018 at 22:23:09 UTC, Walter Bright wrote:

 For example, in any CS program, are there any courses at all 
 about this?


In Year 1 Q4 of my Bachelor CS, there was a course "Software 
Testing and Quality Engineering" which covered things like test 
types (unit, end-to-end, smoke  etc.), code coverage and design 
by contract. They taught how to implement invariants, 
preconditions and postconditions in Java by manually placing 
asserts (since unlike D, there's no `in`, `out` or `invariant` 
keywords in Java) but I don't recall anything related to recovery 
from errors, or using aviation safety principles to make a safe 
system from unreliable parts. They said that you can decide 
between security and performance when choosing to leave asserts 
on/off in release builds.

In Year 2 Q1 there was a follow-up "Software Engineering Methods" 
course which talked about Design Patterns (the GoF ones), process 
(SCRUM / Agile), and designing (with UML and other graphs). No 
other courses since then talked about software engineering, they 
were more focused on specific fields (big data, signal 
processing, embedded systems) and fundamental computer science 
(algorithms, complexity theory, programming languages).
Sep 01 2018
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/1/2018 3:49 AM, Dennis wrote:

 On Friday, 31 August 2018 at 22:23:09 UTC, Walter Bright wrote:

 For example, in any CS program, are there any courses at all about this?


 
 In Year 1 Q4 of my Bachelor CS, there was a course "Software Testing and
Quality 
 Engineering" which covered things like test types (unit, end-to-end, smoke  
 etc.), code coverage and design by contract. They taught how to implement 
 invariants, preconditions and postconditions in Java by manually placing
asserts 
 (since unlike D, there's no `in`, `out` or `invariant` keywords in Java) but I 
 don't recall anything related to recovery from errors, or using aviation
safety 
 principles to make a safe system from unreliable parts. They said that you can 
 decide between security and performance when choosing to leave asserts on/off
in 
 release builds.


Sigh.

It's not just the software industry. Industry outside of aerospace appears to
be 
ignorant of it. See the Deepwater Horizon, Fukushima, medical devices, Toyota 
car computers, it just goes on and on.

One of my favorite examples is when the power failed in New Orleans during a 
storm, and the city flooded. Guess where the backup generators were located? In 
the basements! The flooding took them out. Only one building had power after
the 
disaster, and they'd located the emergency generator above sea level.

Only one did that.

The backups were destroyed by the same situation that caused the need for the 
backups - flooding from power failure. Completely worthless design, because the 
systems were coupled.
Sep 01 2018
prev sibling next sibling parent reply tide <tide tide.tide> writes:
On Friday, 31 August 2018 at 19:50:20 UTC, Walter Bright wrote:

 https://news.ycombinator.com/item?id=17880722

 Typical comments:

 "Stopping all executing may not be the correct 'safe state' for 
 an airplane though!"


Depends on the aircraft and how it is implemented. If you have a 
plane that is fly by wire, and you stop all executing then even 
the pilot no longer has control of the plane anymore, which would 
be very bad.



 "One faction believed you should never intentionally crash the 
 app"

 "One place I worked had a team that was very adamant about not 
 really having much error checking. Not much of any qc process, 
 either. Wait for someone to complain about bad data and 
 respond. Honestly, this worked really well for small, 
 skunkworks type projects that needed to be nimble."

 And on and on. It's unbelievable. The conventional wisdom in 
 software for how to deal with programming bugs simply does not 
 exist.


Depends on the software being developed, for a game? Stopping at 
every assert would be madness. Let a lone having an over 
ubundance of asserts. Can't even imagine how many asserts there 
would be in for something like a matrix multiplication. An 
operation that would otherwise be branchless having numerous 
branches for all the index checks that would be done. Twice per 
scalar value access. And so on and so on.


 Here's the same topic on Reddit with the same awful ideas:

 https://www.reddit.com/r/programming/comments/9bl72d/assertions_in_production_code/

 No wonder that DVD players still hang when you insert a DVD 
 with a scratch on it, and I've had a lot of DVD and Bluray 
 players over the last 20 years. No wonder that malware is 
 everywhere.


TIL people still use DVD players all the while my desktops and 
laptops from the last 7+ years have not even had an optical drive.
Aug 31 2018
next sibling parent reply 0xEAB <desisma heidel.beer> writes:
On Friday, 31 August 2018 at 21:21:16 UTC, tide wrote:

 Depends on the software being developed, for a game? Stopping 
 at every assert would be madness. Let a lone having an over 
 ubundance of asserts. Can't even imagine how many asserts there 
 would be in for something like a matrix multiplication.


If one is aware that something is asserting quite often, why 
don't they just fix the bug that causes that assertion to fail?

Furthermore, how often have we cursed about games that hung up 
with a blackscreen and didn't let us close them by any mean other 
than logging off? If they just crashed, we'd not have run into 
such problems.
Aug 31 2018
parent reply tide <tide tide.tide> writes:
On Friday, 31 August 2018 at 21:31:02 UTC, 0xEAB wrote:

 On Friday, 31 August 2018 at 21:21:16 UTC, tide wrote:

 Depends on the software being developed, for a game? Stopping 
 at every assert would be madness. Let a lone having an over 
 ubundance of asserts. Can't even imagine how many asserts 
 there would be in for something like a matrix multiplication.


 If one is aware that something is asserting quite often, why 
 don't they just fix the bug that causes that assertion to fail?


The asserts being there still cause slow downs in things that 
would otherwise not be slow. Like how D does assert checks for 
indices.


 Furthermore, how often have we cursed about games that hung up 
 with a blackscreen and didn't let us close them by any mean 
 other than logging off? If they just crashed, we'd not have run 
 into such problems.


That's assuming an assert catches every error. Not all bugs are 
going to be caught by an assert. I don't think I've ever had a 
game hung up in a black screen and not be able to close it.
Aug 31 2018
next sibling parent 0xEAB <desisma heidel.beer> writes:
On Friday, 31 August 2018 at 21:40:50 UTC, tide wrote:

 The asserts being there still cause slow downs in things that 
 would otherwise not be slow. Like how D does assert checks for 
 indices.


After the bug is fixed and the app is debugged, there's no need 
to keep those assertions.
The release switch will do the job. Anyway, what's that got to do 
with the topic of this thread?



 That's assuming an assert catches every error. Not all bugs are 
 going to be caught by an assert.


not really, at least that's not what I meant. (well, in theory 
one could write enough assertions to detect any error, but... 
nvm, I agree with you). What I meant were apps misbehaving 
because of obviously ignored errors.



 I don't think I've ever had a game hung up in a black screen 
 and not be able to close it.


Lucky one :)
Aug 31 2018
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Aug 31, 2018 at 09:40:50PM +0000, tide via Digitalmars-d wrote:

 On Friday, 31 August 2018 at 21:31:02 UTC, 0xEAB wrote:


[...]

 Furthermore, how often have we cursed about games that hung up with
 a blackscreen and didn't let us close them by any mean other than
 logging off? If they just crashed, we'd not have run into such
 problems.


 
 That's assuming an assert catches every error. Not all bugs are going
 to be caught by an assert. I don't think I've ever had a game hung up
 in a black screen and not be able to close it.


I have, and that's only one of the better possible scenarios.  I've had
games get into a bad state, which becomes obvious as visual glitches,
and then proceed to silently and subtly corrupt the save file so that on
next startup all progress is lost.

Had the darned thing aborted at the first visual glitch or unexpected
internal state, instead of blindly barging on pretending that visual
glitches are not a real problem, the save file might have still been
salvageable.

(Yes, visual glitches, in and of themselves, aren't a big deal.  Most
people may not even notice them.  But when they happen unexpectedly,
they can be a symptom of a deeper, far more serious problem. Just like
an assert detecting that some variable isn't the expected value. Maybe
the variable isn't even anything important; maybe it just controls the
color of the title bar or something equally irrelevant. But it could be
a sign that there's been a memory corruption.  It could be a sign that
the program is in the middle of being exploited by a security hack. The
unexpected value in the variable isn't merely an irrelevant thing that
we can safely ignore; it could be circumstantial evidence of something
far more serious.  Continuing to barrel forward in spite of clear
evidence pointing to a problem is utterly foolish.)


T

-- 
Latin's a dead language, as dead as can be; it killed off all the Romans, and
now it's killing me! -- Schoolboy
Aug 31 2018
parent reply tide <tide tide.tide> writes:
On Friday, 31 August 2018 at 22:05:18 UTC, H. S. Teoh wrote:

 On Fri, Aug 31, 2018 at 09:40:50PM +0000, tide via 
 Digitalmars-d wrote:

 On Friday, 31 August 2018 at 21:31:02 UTC, 0xEAB wrote:


 [...]

 Furthermore, how often have we cursed about games that hung 
 up with a blackscreen and didn't let us close them by any 
 mean other than logging off? If they just crashed, we'd not 
 have run into such problems.


 
 That's assuming an assert catches every error. Not all bugs 
 are going to be caught by an assert. I don't think I've ever 
 had a game hung up in a black screen and not be able to close 
 it.


 I have, and that's only one of the better possible scenarios.  
 I've had games get into a bad state, which becomes obvious as 
 visual glitches, and then proceed to silently and subtly 
 corrupt the save file so that on next startup all progress is 
 lost.

 Had the darned thing aborted at the first visual glitch or 
 unexpected internal state, instead of blindly barging on 
 pretending that visual glitches are not a real problem, the 
 save file might have still been salvageable.

 (Yes, visual glitches, in and of themselves, aren't a big deal.
  Most people may not even notice them.  But when they happen 
 unexpectedly, they can be a symptom of a deeper, far more 
 serious problem. Just like an assert detecting that some 
 variable isn't the expected value. Maybe the variable isn't 
 even anything important; maybe it just controls the color of 
 the title bar or something equally irrelevant. But it could be 
 a sign that there's been a memory corruption.  It could be a 
 sign that the program is in the middle of being exploited by a 
 security hack. The unexpected value in the variable isn't 
 merely an irrelevant thing that we can safely ignore; it could 
 be circumstantial evidence of something far more serious.  
 Continuing to barrel forward in spite of clear evidence 
 pointing to a problem is utterly foolish.)


 T


I'm just wondering but how would you code an assert to ensure the 
variable for a title bar is the correct color? Just how many 
asserts are you going to have in your real-time game that can be 
expected to run at 144+ fps ?
Aug 31 2018
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/31/2018 7:28 PM, tide wrote:

 I'm just wondering but how would you code an assert to ensure the variable for
a 
 title bar is the correct color? Just how many asserts are you going to have in 
 your real-time game that can be expected to run at 144+ fps ?


Experience will guide you on where to put the asserts.

But really, just apply common sense. It's not just for software. If you're a 
physicist, and your calculations come up with a negative mass, you screwed up. 
If you're a mechanical engineer, and calculate a force of billion pounds from 
dropping a piano, you screwed up. If you're an accountant, and calculate that 
you owe a million dollars in taxes on a thousand dollars of income, you screwed 
up. If you build a diagnostic X-ray machine, and the control software computes
a 
lethal dose to administer, you screwed up.

Apply common sense and assert on unreasonable results, because your code is
broken.
Sep 01 2018
next sibling parent Dennis <dkorpel gmail.com> writes:
On Saturday, 1 September 2018 at 08:18:03 UTC, Walter Bright 
wrote:

 On 8/31/2018 7:28 PM, tide wrote:

 I'm just wondering but how would you code an assert to ensure 
 the variable for a title bar is the correct color? Just how 
 many asserts are you going to have in your real-time game that 
 can be expected to run at 144+ fps ?


 Experience will guide you on where to put the asserts.

 (...)

 Apply common sense and assert on unreasonable results, because 
 your code is broken.


Your examples are valid, but I just wanted to say the game 
development is a bit of a 'special' case in software engineering 
because there is often no clear 'correct' output for an input. 
The desired output is simply one that makes the players happy, 
which is subjective.

Take for example a 3D game where a car gets stuck between 
bollards and launches into the air. The problem is that real-time 
physics engines work in discrete steps and try to solve 
constraints by adding force to push overlapping bodies away from 
each other. When a rigid body gets stuck inside another rigid 
body, the force it generates can be comically large. This problem 
is well known but a 'proper' fix is not easy, it's often solved 
by designing the geometry so that cars can't get stuck like that. 
Would an `assert(car.yVelocity < 200 m/s)` that causes the game 
to crash when that happens really make the game better? Many 
players actually enjoy such glitches. They don't like when their 
character randomly clips through the floor and falls into a void 
however. But how would you assert that doesn't happen? There's no 
formal definition for it.

By the way, I'm sure the way the Unity game engine treats asserts 
will make you cry:
"A failure of an assertion method does not break the control flow 
of the execution. On a failure, an assertion message is logged 
(LogType.Assert) and the execution continues."[1]

That's in debug builds, in release builds they are removed 
completely. So my `Assert.IsNotNull()` fails but the assert 
message quickly gets buried under a slew of errors. Note that the 

question just ceases to work. "The show must go on!"

[1] 
https://docs.unity3d.com/ScriptReference/Assertions.Assert.html
Sep 01 2018
prev sibling next sibling parent reply tide <tide tide.tide> writes:
On Saturday, 1 September 2018 at 08:18:03 UTC, Walter Bright 
wrote:

 On 8/31/2018 7:28 PM, tide wrote:

 I'm just wondering but how would you code an assert to ensure 
 the variable for a title bar is the correct color? Just how 
 many asserts are you going to have in your real-time game that 
 can be expected to run at 144+ fps ?


 Experience will guide you on where to put the asserts.

 But really, just apply common sense. It's not just for 
 software. If you're a physicist, and your calculations come up 
 with a negative mass, you screwed up. If you're a mechanical 
 engineer, and calculate a force of billion pounds from dropping 
 a piano, you screwed up. If you're an accountant, and calculate 
 that you owe a million dollars in taxes on a thousand dollars 
 of income, you screwed up. If you build a diagnostic X-ray 
 machine, and the control software computes a lethal dose to 
 administer, you screwed up.

 Apply common sense and assert on unreasonable results, because 
 your code is broken.


That's what he, and apparently you don't get. How are you going 
to use an assert to check that the color of a title bar is valid? 
Try and implement that assert, and let me know what you come up 
with.
Sep 01 2018
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 02/09/2018 12:37 AM, tide wrote:

 On Saturday, 1 September 2018 at 08:18:03 UTC, Walter Bright wrote:

 On 8/31/2018 7:28 PM, tide wrote:

 I'm just wondering but how would you code an assert to ensure the 
 variable for a title bar is the correct color? Just how many asserts 
 are you going to have in your real-time game that can be expected to 
 run at 144+ fps ?


 Experience will guide you on where to put the asserts.

 But really, just apply common sense. It's not just for software. If 
 you're a physicist, and your calculations come up with a negative 
 mass, you screwed up. If you're a mechanical engineer, and calculate a 
 force of billion pounds from dropping a piano, you screwed up. If 
 you're an accountant, and calculate that you owe a million dollars in 
 taxes on a thousand dollars of income, you screwed up. If you build a 
 diagnostic X-ray machine, and the control software computes a lethal 
 dose to administer, you screwed up.

 Apply common sense and assert on unreasonable results, because your 
 code is broken.


 
 That's what he, and apparently you don't get. How are you going to use 
 an assert to check that the color of a title bar is valid? Try and 
 implement that assert, and let me know what you come up with.


If you have the ability to screenshot a window like I do, oh one simple 
method call is all that required with a simple index to get the color.

But that isn't something I'd go test... Too much system-y stuff that can 
modify it.
Sep 01 2018
parent reply tide <tide tide.tide> writes:
On Saturday, 1 September 2018 at 12:49:12 UTC, rikki cattermole 
wrote:

 On 02/09/2018 12:37 AM, tide wrote:

 On Saturday, 1 September 2018 at 08:18:03 UTC, Walter Bright 
 wrote:

 On 8/31/2018 7:28 PM, tide wrote:

 I'm just wondering but how would you code an assert to 
 ensure the variable for a title bar is the correct color? 
 Just how many asserts are you going to have in your 
 real-time game that can be expected to run at 144+ fps ?


 Experience will guide you on where to put the asserts.

 But really, just apply common sense. It's not just for 
 software. If you're a physicist, and your calculations come 
 up with a negative mass, you screwed up. If you're a 
 mechanical engineer, and calculate a force of billion pounds 
 from dropping a piano, you screwed up. If you're an 
 accountant, and calculate that you owe a million dollars in 
 taxes on a thousand dollars of income, you screwed up. If you 
 build a diagnostic X-ray machine, and the control software 
 computes a lethal dose to administer, you screwed up.

 Apply common sense and assert on unreasonable results, 
 because your code is broken.


 
 That's what he, and apparently you don't get. How are you 
 going to use an assert to check that the color of a title bar 
 is valid? Try and implement that assert, and let me know what 
 you come up with.


 If you have the ability to screenshot a window like I do, oh 
 one simple method call is all that required with a simple index 
 to get the color.

 But that isn't something I'd go test... Too much system-y stuff 
 that can modify it.


And you're putting that into production code? Cause that's the 
entire point of this topic :).
Sep 01 2018
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 02/09/2018 12:57 AM, tide wrote:

 On Saturday, 1 September 2018 at 12:49:12 UTC, rikki cattermole wrote:

 On 02/09/2018 12:37 AM, tide wrote:

 On Saturday, 1 September 2018 at 08:18:03 UTC, Walter Bright wrote:

 On 8/31/2018 7:28 PM, tide wrote:

 I'm just wondering but how would you code an assert to ensure the 
 variable for a title bar is the correct color? Just how many 
 asserts are you going to have in your real-time game that can be 
 expected to run at 144+ fps ?


 Experience will guide you on where to put the asserts.

 But really, just apply common sense. It's not just for software. If 
 you're a physicist, and your calculations come up with a negative 
 mass, you screwed up. If you're a mechanical engineer, and calculate 
 a force of billion pounds from dropping a piano, you screwed up. If 
 you're an accountant, and calculate that you owe a million dollars 
 in taxes on a thousand dollars of income, you screwed up. If you 
 build a diagnostic X-ray machine, and the control software computes 
 a lethal dose to administer, you screwed up.

 Apply common sense and assert on unreasonable results, because your 
 code is broken.


 That's what he, and apparently you don't get. How are you going to 
 use an assert to check that the color of a title bar is valid? Try 
 and implement that assert, and let me know what you come up with.


 If you have the ability to screenshot a window like I do, oh one 
 simple method call is all that required with a simple index to get the 
 color.

 But that isn't something I'd go test... Too much system-y stuff that 
 can modify it.


 
 And you're putting that into production code? Cause that's the entire 
 point of this topic :).


Goodness no. I can BSOD Windows just by writing user-land code that 
pretty much every program uses (yes related). Some things can definitely 
be tested in an assert, however like Walter has been arguing, are better 
left untested in production.

Keep in mind, a window whose decorations has changed color, is a very 
reasonable and should be expected situation. It is no where near an error.

This is one of the reasons I wouldn't bother with automated UI testing. 
Too many things can make it fail that is not related to your code, and 
integration may as well not exist cross-platform anyway. Let alone be 
well defined.
Sep 01 2018
parent tide <tide tide.tide> writes:
On Saturday, 1 September 2018 at 13:03:50 UTC, rikki cattermole 
wrote:

 On 02/09/2018 12:57 AM, tide wrote:

 On Saturday, 1 September 2018 at 12:49:12 UTC, rikki 
 cattermole wrote:

 On 02/09/2018 12:37 AM, tide wrote:

 On Saturday, 1 September 2018 at 08:18:03 UTC, Walter Bright 
 wrote:

 On 8/31/2018 7:28 PM, tide wrote:

 I'm just wondering but how would you code an assert to 
 ensure the variable for a title bar is the correct color? 
 Just how many asserts are you going to have in your 
 real-time game that can be expected to run at 144+ fps ?


 Experience will guide you on where to put the asserts.

 But really, just apply common sense. It's not just for 
 software. If you're a physicist, and your calculations come 
 up with a negative mass, you screwed up. If you're a 
 mechanical engineer, and calculate a force of billion 
 pounds from dropping a piano, you screwed up. If you're an 
 accountant, and calculate that you owe a million dollars in 
 taxes on a thousand dollars of income, you screwed up. If 
 you build a diagnostic X-ray machine, and the control 
 software computes a lethal dose to administer, you screwed 
 up.

 Apply common sense and assert on unreasonable results, 
 because your code is broken.


 That's what he, and apparently you don't get. How are you 
 going to use an assert to check that the color of a title 
 bar is valid? Try and implement that assert, and let me know 
 what you come up with.


 If you have the ability to screenshot a window like I do, oh 
 one simple method call is all that required with a simple 
 index to get the color.

 But that isn't something I'd go test... Too much system-y 
 stuff that can modify it.


 
 And you're putting that into production code? Cause that's the 
 entire point of this topic :).


 like Walter has been arguing, are better left untested in 
 production.


That's not what Walter has been arguing.
Sep 01 2018
prev sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Saturday, September 1, 2018 6:37:13 AM MDT tide via Digitalmars-d wrote:

 On Saturday, 1 September 2018 at 08:18:03 UTC, Walter Bright

 wrote:

 On 8/31/2018 7:28 PM, tide wrote:

 I'm just wondering but how would you code an assert to ensure
 the variable for a title bar is the correct color? Just how
 many asserts are you going to have in your real-time game that
 can be expected to run at 144+ fps ?


 Experience will guide you on where to put the asserts.

 But really, just apply common sense. It's not just for
 software. If you're a physicist, and your calculations come up
 with a negative mass, you screwed up. If you're a mechanical
 engineer, and calculate a force of billion pounds from dropping
 a piano, you screwed up. If you're an accountant, and calculate
 that you owe a million dollars in taxes on a thousand dollars
 of income, you screwed up. If you build a diagnostic X-ray
 machine, and the control software computes a lethal dose to
 administer, you screwed up.

 Apply common sense and assert on unreasonable results, because
 your code is broken.


 That's what he, and apparently you don't get. How are you going
 to use an assert to check that the color of a title bar is valid?
 Try and implement that assert, and let me know what you come up
 with.


I don't think that H. S. Teoh's point was so much that you should be
asserting anything about the colors in the graphics but rather that problems
in the graphics could be a sign of a deeper, more critical problem and that
as such the fact that there are graphical glitches is not necessary
innocuous. However, presumably, if you're going to put assertions in that
code, you'd assert things about the actual logic that seems critical and not
anything about the colors or whatnot - though if the graphical problems
would be a sign of a deeper problem, then the assertions could then prevent
the graphical problems, since the program would be killed before they
happened due to the assertions about the core logic failing.

- Jonathan M Davis
Sep 01 2018
parent reply tide <tide tide.tide> writes:
On Saturday, 1 September 2018 at 13:21:27 UTC, Jonathan M Davis 
wrote:

 On Saturday, September 1, 2018 6:37:13 AM MDT tide via 
 Digitalmars-d wrote:

 On Saturday, 1 September 2018 at 08:18:03 UTC, Walter Bright

 wrote:

 On 8/31/2018 7:28 PM, tide wrote:

 I'm just wondering but how would you code an assert to 
 ensure the variable for a title bar is the correct color? 
 Just how many asserts are you going to have in your 
 real-time game that can be expected to run at 144+ fps ?


 Experience will guide you on where to put the asserts.

 But really, just apply common sense. It's not just for 
 software. If you're a physicist, and your calculations come 
 up with a negative mass, you screwed up. If you're a 
 mechanical engineer, and calculate a force of billion pounds 
 from dropping a piano, you screwed up. If you're an 
 accountant, and calculate that you owe a million dollars in 
 taxes on a thousand dollars of income, you screwed up. If 
 you build a diagnostic X-ray machine, and the control 
 software computes a lethal dose to administer, you screwed 
 up.

 Apply common sense and assert on unreasonable results, 
 because your code is broken.


 That's what he, and apparently you don't get. How are you 
 going to use an assert to check that the color of a title bar 
 is valid? Try and implement that assert, and let me know what 
 you come up with.


 I don't think that H. S. Teoh's point was so much that you 
 should be asserting anything about the colors in the graphics 
 but rather that problems in the graphics could be a sign of a 
 deeper, more critical problem and that as such the fact that 
 there are graphical glitches is not necessary innocuous. 
 However, presumably, if you're going to put assertions in that 
 code, you'd assert things about the actual logic that seems 
 critical and not anything about the colors or whatnot - though 
 if the graphical problems would be a sign of a deeper problem, 
 then the assertions could then prevent the graphical problems, 
 since the program would be killed before they happened due to 
 the assertions about the core logic failing.

 - Jonathan M Davis


Any graphic problems are going to stem probably more from shaders 
and interaction with the GPU than any sort of logic code. Not 
that you can really use asserts to ensure you are making calls to 
something like Vulkan correctly. There are validation layers for 
that, which are more helpful than assert would ever be. They 
still have a cost, as an example my engine runs at 60+ FPS on my 
crappy phone without the validation layers. But with them enabled 
I get roughly less than half that 10-15 fps, depending on where 
I'm looking. So using them in production code isn't exactly 
possible.


What he was talking about was basically that, he was saying how 
it could be used to identify possible memory corruption, which is 
completely absurd. That's just stretching it's use case so thin.
Sep 02 2018
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Sep 03, 2018 at 03:21:00AM +0000, tide via Digitalmars-d wrote:
[...]

 Any graphic problems are going to stem probably more from shaders and
 interaction with the GPU than any sort of logic code.


[...]

 What he was talking about was basically that, he was saying how it
 could be used to identify possible memory corruption, which is
 completely absurd.  That's just stretching it's use case so thin.


You misquote me. I never said asserts could be used to *identify* memory
corruption -- that's preposterous.  What I'm saying is that when an
assert failed, it *may* be caused by a memory corruption (among many
other possibilities), and that is one of the reasons why it's a bad idea
to keep going in spite of the assertion failure.

The reason I picked memory corruption is because it's a good
illustration of how badly things can go wrong when code that is known to
have programming bugs continue running unchecked.  When an assertion
fails it basically means the program has a logic error, and what the
programmer assumed the program will do is wrong.  Therefore, by
definition, you cannot predict what the program will actually do -- and
remote exploits via memory corruption is a good example of how your
program can end up doing something completely different from what it was
designed to do when you keep going in spite of logic errors.

Obviously, assertions aren't going to catch *all* memory corruptions,
but given that an assertion failure *might* be caused by a memory
corruption, why would anyone in their sane mind want to allow the
program to keep going?  We cannot catch *all* logic errors by
assertions, but why would anyone want to deliberately ignore the logic
errors that we *can* catch?


T

-- 
If creativity is stifled by rigid discipline, then it is not true creativity.
Sep 02 2018
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Sep 02, 2018 at 09:33:36PM -0700, H. S. Teoh wrote:
[...]

 The reason I picked memory corruption is because it's a good
 illustration of how badly things can go wrong when code that is known to
 have programming bugs continue running unchecked.


[...]

P.S. And memory corruption is also a good illustration of how a logic
error in one part of the program can cause another completely unrelated
part of the program to malfunction.  The corruption could have happened
in your network stack, but it overwrites memory used by your GPU code.
You cannot simply assume that just because the network module has
nothing to do with the GPU module, that a GPU code assertion failure
cannot be caused by a memory corruption in the network module.
Therefore, you also cannot assume that an assertion in the GPU code can
be safely ignored, because by definition, the program's logic is flawed,
and so any assumptions you may have made about it may no longer be true,
and blindly continuing to run the code means the possibility of actually
executing a remote exploit instead of the GPU code you thought you were
about to execute.

When the program logic is known to be flawed, by definition the program
is in an invalid state with unknown (and unknowable -- because it
implies that your assumptions were false) consequences.  The only safe
recourse is to terminate the program to get out of that state and
restart from a known safe state.  Anything less is unsafe, because being
in an invalid state means you cannot predict what the program will do
when you try to recover it.  Your state graph may look nothing like what
you thought it should look like, so an action that you thought would
bring the program into a known state may in fact bring it into a
different, unknown state, which can exhibit any arbitrary behaviour.
(This is why certain security holes are known as "arbitrary code
execution": the attacker exploits a loophole in the program's state
graph to do something the programmer never thought the program could do
-- because the programmer's assumptions turned out to be wrong.)


T

-- 
This sentence is false.
Sep 02 2018
parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 09/03/2018 12:46 AM, H. S. Teoh wrote:

 On Sun, Sep 02, 2018 at 09:33:36PM -0700, H. S. Teoh wrote:
 [...]

 The reason I picked memory corruption is because it's a good
 illustration of how badly things can go wrong when code that is known to
 have programming bugs continue running unchecked.


 [...]
 
 P.S. And memory corruption is also a good illustration of how a logic
 error in one part of the program can cause another completely unrelated
 part of the program to malfunction.  The corruption could have happened
 in your network stack, but it overwrites memory used by your GPU code.
 You cannot simply assume that just because the network module has
 nothing to do with the GPU module, that a GPU code assertion failure
 cannot be caused by a memory corruption in the network module.
 Therefore, you also cannot assume that an assertion in the GPU code can
 be safely ignored, because by definition, the program's logic is flawed,
 and so any assumptions you may have made about it may no longer be true,
 and blindly continuing to run the code means the possibility of actually
 executing a remote exploit instead of the GPU code you thought you were
 about to execute.
 


Isn't that assuming the parts aren't  safe? ;)


 Anything less is unsafe, because being
 in an invalid state means you cannot predict what the program will do
 when you try to recover it.  Your state graph may look nothing like what
 you thought it should look like, so an action that you thought would
 bring the program into a known state may in fact bring it into a
 different, unknown state, which can exhibit any arbitrary behaviour.


You mean attempting to doing things, like say, generate a stack trace or 
format/display the name of the Error class and a diagnostic message? ;)

Not to say it's all-or-nothing of course, but suppose it IS memory 
corruption and trying to continue WILL cause some bigger problem like 
arbitrary code execution. In that case, won't the standard Error class 
stuff still just trigger that bigger problem, anyway?
Sep 02 2018
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Sunday, September 2, 2018 11:54:57 PM MDT Nick Sabalausky (Abscissa) via 
Digitalmars-d wrote:

 On 09/03/2018 12:46 AM, H. S. Teoh wrote:

 Anything less is unsafe, because being
 in an invalid state means you cannot predict what the program will do
 when you try to recover it.  Your state graph may look nothing like what
 you thought it should look like, so an action that you thought would
 bring the program into a known state may in fact bring it into a
 different, unknown state, which can exhibit any arbitrary behaviour.


 You mean attempting to doing things, like say, generate a stack trace or
 format/display the name of the Error class and a diagnostic message? ;)

 Not to say it's all-or-nothing of course, but suppose it IS memory
 corruption and trying to continue WILL cause some bigger problem like
 arbitrary code execution. In that case, won't the standard Error class
 stuff still just trigger that bigger problem, anyway?


Throwing an Error is a lot less likely to cause problems than actually
trying to recover. However, personally, I'm increasingly of the opinion that
the best thing to do would be to not have Errors but to kill the program at
the point of failure. That way, you could get a coredump at the point of
failure, with all of the state that goes with it, making it easier to debug,
and it would be that much less likely to cause any more problems before the
program actually exits. You might still have it print an error message and
stack trace before triggering a HLT or whatever, but I think that that's the
most that I would have it do. And while doing that would still potentially
open up problems, unless someone hijacked that specific piece of code, it
would likely be fine, and it would _really_ help on systems that don't have
coredumps enabled - not to mention seeing that in the log could make
bringing up the coredump in the debugger unnecessary in some cases.
Regardless, getting a coredump at the point of failure would be far better
IMHO than what we currently have with Errors.

- Jonathan M Davis
Sep 02 2018
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/1/2018 1:18 AM, Walter Bright wrote:

 On 8/31/2018 7:28 PM, tide wrote:

 I'm just wondering but how would you code an assert to ensure the variable for 
 a title bar is the correct color? Just how many asserts are you going to have 
 in your real-time game that can be expected to run at 144+ fps ?


 [...]


John Regehr has some excellent advice, much better than mine:

https://blog.regehr.org/archives/1091
Sep 01 2018
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/31/2018 2:40 PM, tide wrote:

 I don't think I've ever had a game hung up in a black 
 screen and not be able to close it.


I've had that problem with every DVD player I've had in the last 20 years.
Power 
cycling is the only fix.
Aug 31 2018
parent reply tide <tide tide.tide> writes:
On Friday, 31 August 2018 at 22:42:39 UTC, Walter Bright wrote:

 On 8/31/2018 2:40 PM, tide wrote:

 I don't think I've ever had a **game** hung up in a black 
 screen and not be able to close it.


 I've had that problem with every **DVD player** I've had in the 
 last 20 years. Power cycling is the only fix.


Two very different things, odds are your DVD players code aren't 
even written with a complete C compiler or libraries.
Aug 31 2018
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 01/09/2018 12:40 PM, tide wrote:

 On Friday, 31 August 2018 at 22:42:39 UTC, Walter Bright wrote:

 On 8/31/2018 2:40 PM, tide wrote:

 I don't think I've ever had a **game** hung up in a black screen and 
 not be able to close it.


 I've had that problem with every **DVD player** I've had in the last 
 20 years. Power cycling is the only fix.


 
 Two very different things, odds are your DVD players code aren't even 
 written with a complete C compiler or libraries.


And yet they manage to run a JVM with Java on it.
Aug 31 2018
parent reply tide <tide tide.tide> writes:
On Saturday, 1 September 2018 at 05:53:12 UTC, rikki cattermole 
wrote:

 On 01/09/2018 12:40 PM, tide wrote:

 On Friday, 31 August 2018 at 22:42:39 UTC, Walter Bright wrote:

 On 8/31/2018 2:40 PM, tide wrote:

 I don't think I've ever had a **game** hung up in a black 
 screen and not be able to close it.


 I've had that problem with every **DVD player** I've had in 
 the last 20 years. Power cycling is the only fix.


 
 Two very different things, odds are your DVD players code 
 aren't even written with a complete C compiler or libraries.


 And yet they manage to run a JVM with Java on it.


Not the one's Walter is talking about. I rarely have to power 
cycle any smart device, even my phone which is running so much 
shit on it.
Sep 01 2018
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 02/09/2018 12:21 AM, tide wrote:

 On Saturday, 1 September 2018 at 05:53:12 UTC, rikki cattermole wrote:

 On 01/09/2018 12:40 PM, tide wrote:

 On Friday, 31 August 2018 at 22:42:39 UTC, Walter Bright wrote:

 On 8/31/2018 2:40 PM, tide wrote:

 I don't think I've ever had a **game** hung up in a black screen 
 and not be able to close it.


 I've had that problem with every **DVD player** I've had in the last 
 20 years. Power cycling is the only fix.


 Two very different things, odds are your DVD players code aren't even 
 written with a complete C compiler or libraries.


 And yet they manage to run a JVM with Java on it.


 
 Not the one's Walter is talking about. I rarely have to power cycle any 
 smart device, even my phone which is running so much shit on it.


For some reason I have memories related to DVD players containing a JVM 
to provide interactivity. But it doesn't look like those memory were 
based on anything. So ignore me.
Sep 01 2018
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Saturday, September 1, 2018 6:46:38 AM MDT rikki cattermole via 
Digitalmars-d wrote:

 On 02/09/2018 12:21 AM, tide wrote:

 On Saturday, 1 September 2018 at 05:53:12 UTC, rikki cattermole wrote:

 On 01/09/2018 12:40 PM, tide wrote:

 On Friday, 31 August 2018 at 22:42:39 UTC, Walter Bright wrote:

 On 8/31/2018 2:40 PM, tide wrote:

 I don't think I've ever had a **game** hung up in a black screen
 and not be able to close it.


 I've had that problem with every **DVD player** I've had in the last
 20 years. Power cycling is the only fix.


 Two very different things, odds are your DVD players code aren't even
 written with a complete C compiler or libraries.


 And yet they manage to run a JVM with Java on it.


 Not the one's Walter is talking about. I rarely have to power cycle any
 smart device, even my phone which is running so much shit on it.


 For some reason I have memories related to DVD players containing a JVM
 to provide interactivity. But it doesn't look like those memory were
 based on anything. So ignore me.


I don't know if any DVD players have ever used Java, but all Blu-ray players
do require it, because unfortunately, the Blu-ray spec allows for the menus
to be done via Java (presumably so that they can be fancier than what was
possible on DVDs).

- Jonathan M Davis
Sep 01 2018
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 02/09/2018 1:15 AM, Jonathan M Davis wrote:

 On Saturday, September 1, 2018 6:46:38 AM MDT rikki cattermole via
 Digitalmars-d wrote:

 On 02/09/2018 12:21 AM, tide wrote:

 On Saturday, 1 September 2018 at 05:53:12 UTC, rikki cattermole wrote:

 On 01/09/2018 12:40 PM, tide wrote:

 On Friday, 31 August 2018 at 22:42:39 UTC, Walter Bright wrote:

 On 8/31/2018 2:40 PM, tide wrote:

 I don't think I've ever had a **game** hung up in a black screen
 and not be able to close it.


 I've had that problem with every **DVD player** I've had in the last
 20 years. Power cycling is the only fix.


 Two very different things, odds are your DVD players code aren't even
 written with a complete C compiler or libraries.


 And yet they manage to run a JVM with Java on it.


 Not the one's Walter is talking about. I rarely have to power cycle any
 smart device, even my phone which is running so much shit on it.


 For some reason I have memories related to DVD players containing a JVM
 to provide interactivity. But it doesn't look like those memory were
 based on anything. So ignore me.


 
 I don't know if any DVD players have ever used Java, but all Blu-ray players
 do require it, because unfortunately, the Blu-ray spec allows for the menus
 to be done via Java (presumably so that they can be fancier than what was
 possible on DVDs).
 
 - Jonathan M Davis


Harry potter 1&2 had games as part of their menus as of 2001/2, so it 
was already pretty sophisticated.
Sep 01 2018
prev sibling parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 09/01/2018 09:15 AM, Jonathan M Davis wrote:

 
 I don't know if any DVD players have ever used Java, but all Blu-ray players
 do require it, because unfortunately, the Blu-ray spec allows for the menus
 to be done via Java (presumably so that they can be fancier than what was
 possible on DVDs).
 


DVDs (PUOs)...BluRays (Java)...Web...

All evidence that the more technical power you give content creators, 
the bigger the design abominations they'll subject the world to ;) [1]

I actually once came across a professionally-produced, major-studio 
BluRay where pressing Pause didn't pause the video, but actually made it 
deliberately switch over to and play a *different* video instead.

This is why a good system is one that automatically does the right thing 
by default, and makes you work to do the wrong thing...if it's even 
important enough to have the escape hatch.

[1] That, of course, is not an "us-vs-them" statement: Programmers are 
by definition content creators, too!
Sep 01 2018
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/31/2018 5:40 PM, tide wrote:

 On Friday, 31 August 2018 at 22:42:39 UTC, Walter Bright wrote:

 On 8/31/2018 2:40 PM, tide wrote:

 I don't think I've ever had a **game** hung up in a black screen and not be 
 able to close it.


 I've had that problem with every **DVD player** I've had in the last 20 years. 
 Power cycling is the only fix.


 
 Two very different things, odds are your DVD players code aren't even written 
 with a complete C compiler or libraries.


Doesn't matter. It's clear that DVD player software is written by cowboy 
programmers who likely believe that it's fine to continue running a program 
after it has entered an invalid state, presumably to avoid annoying customers.

Newer DVD/Bluray players have an ethernet port on the back. I'd never connect 
such a P.O.S. malware incubator to my LAN.
Sep 01 2018
next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Saturday, September 1, 2018 1:59:27 AM MDT Walter Bright via Digitalmars-
d wrote:

 On 8/31/2018 5:40 PM, tide wrote:

 On Friday, 31 August 2018 at 22:42:39 UTC, Walter Bright wrote:

 On 8/31/2018 2:40 PM, tide wrote:

 I don't think I've ever had a **game** hung up in a black screen and
 not be able to close it.


 I've had that problem with every **DVD player** I've had in the last 20
 years. Power cycling is the only fix.


 Two very different things, odds are your DVD players code aren't even
 written with a complete C compiler or libraries.


 Doesn't matter. It's clear that DVD player software is written by cowboy
 programmers who likely believe that it's fine to continue running a
 program after it has entered an invalid state, presumably to avoid
 annoying customers.

 Newer DVD/Bluray players have an ethernet port on the back. I'd never
 connect such a P.O.S. malware incubator to my LAN.


Unfortunately, in the case of Blu-ray players, if you don't, at some point,
you likely won't be able to play newer Blu-rays, because they keep updating
the DRM on the discs, requiring updates to the players - which is annoying
enough on its own, but when you consider that if it weren't for the DRM,
there wouldn't be any reason to hook up a Blu-ray player to a network, the
fact that the DRM essentially requires it is that much more egregious. But
sadly, increasingly, they seem to want you to hook up all of your stray
electronics to the network, which is anything but safe. Fortunately, not all
of them actually require it (e.g. I've never hooked up my TV to any network,
and I see no value in anything it runs that would require it), but too many
do.

- Jonathan M Davis
Sep 01 2018
prev sibling parent reply tide <tide tide.tide> writes:
On Saturday, 1 September 2018 at 07:59:27 UTC, Walter Bright 
wrote:

 On 8/31/2018 5:40 PM, tide wrote:

 On Friday, 31 August 2018 at 22:42:39 UTC, Walter Bright wrote:

 On 8/31/2018 2:40 PM, tide wrote:

 I don't think I've ever had a **game** hung up in a black 
 screen and not be able to close it.


 I've had that problem with every **DVD player** I've had in 
 the last 20 years. Power cycling is the only fix.


 
 Two very different things, odds are your DVD players code 
 aren't even written with a complete C compiler or libraries.


 Doesn't matter. It's clear that DVD player software is written 
 by cowboy programmers who likely believe that it's fine to 
 continue running a program after it has entered an invalid 
 state, presumably to avoid annoying customers.

 Newer DVD/Bluray players have an ethernet port on the back. I'd 
 never connect such a P.O.S. malware incubator to my LAN.


It does matter, I've programmed on embedded systems where the 
filename length was limited to 10 or so characters. There were 
all kinds of restrictions, how do you know when you have to power 
cycle that isn't an assert being hit and having the powercycle is 
the result of a hardware limitation that these "cowboy 
programmers" had no control over ? You are making a lot of wild 
assumptions to try and prove a point, and that all bugs can be 
solved with asserts (which they can't). Hey guys race conditions 
aren't a problem, just use an assert, mission fucking 
accomplished.
Sep 01 2018
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/1/2018 5:25 AM, tide wrote:

 and that all bugs can be solved with asserts


I never said that, not even close.

But I will maintain that DVD players still hanging on a scratched DVD after 20 
years of development means there's some cowboy engineering going on, and an 
obvious lack of concern about that from the manufacturer.
Sep 01 2018
next sibling parent Norm <norm.rowtree gmail.com> writes:
On Saturday, 1 September 2018 at 20:48:27 UTC, Walter Bright 
wrote:

 On 9/1/2018 5:25 AM, tide wrote:

 and that all bugs can be solved with asserts


 I never said that, not even close.

 But I will maintain that DVD players still hanging on a 
 scratched DVD after 20 years of development means there's some 
 cowboy engineering going on, and an obvious lack of concern 
 about that from the manufacturer.


Firstly, you have to take into account the context around why 
that bug exists and why it is not fixed and it comes does to a 
risk-cost trade off.

Product managers are totally driven by budget and in consumer 
goods they dictate the engineering resources. I think you'll find 
most large DVD manufactures have discovered that it is not cost 
effective to give engineers the budget to fix these annoying 
bugs. This is because most consumers will be annoyed but then go 
out and purchase som other product by the same manufacturer. I.e. 
these bugs do not harm their brand enough.

This leads to the situation where the engineering is shoddy not 
because the programmers are bad engineers, but because they don't 
even get the chance to engineer due to time constraints.

Secondly, DVD players and critical flight systems are apples and 
oranges in terms of engineering rigor required. One will mildly 
annoy the odd consumer, who 9 times of 10 will still purchase 
<Insert Brand Here> products again and the other will likely kill 
100s of people.

To put it another way; one will give the engineers *zero* 
resources to work on non-blocking bugs and the other must have 
*zero* non-blocking bugs.

Cheers,
Norm
Sep 01 2018
prev sibling parent reply tide <tide tide.tide> writes:
On Saturday, 1 September 2018 at 20:48:27 UTC, Walter Bright 
wrote:

 On 9/1/2018 5:25 AM, tide wrote:

 and that all bugs can be solved with asserts


 I never said that, not even close.


Are you in large implying it.


 But I will maintain that DVD players still hanging on a 
 scratched DVD after 20 years of development means there's some 
 cowboy engineering going on, and an obvious lack of concern 
 about that from the manufacturer.


Yes why wouldn't a company want to fix a "feature" where by, if 
you have a scratch on a DVD you have to go buy another one in 
order to play it. It's obviously not that big of a deal breaker, 
even for you, considering you are still buying them 20 years on.
Sep 03 2018
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/3/2018 8:33 AM, tide wrote:

 Yes why wouldn't a company want to fix a "feature" where by, if you have a 
 scratch on a DVD you have to go buy another one in order to play it.


Not playing it with an appropriate message is fine. Hanging the machine is not.



 It's obviously not that big of a deal breaker, even for you, considering you
are 
 still buying them 20 years on.


Or more likely, I buy another one now and then that will hopefully behave
better.

I've found that different DVD players will play different damaged DVDs, i.e.
one 
that will play one DVD won't play another, and vice versa.

I can get DVD players from the thrift store for $5, it's cheaper than buying a 
replacement DVD :-)
Sep 03 2018
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/31/2018 2:21 PM, tide wrote:

 On Friday, 31 August 2018 at 19:50:20 UTC, Walter Bright wrote:

 "Stopping all executing may not be the correct 'safe state' for an airplane 
 though!"


 Depends on the aircraft and how it is implemented. If you have a plane that is 
 fly by wire, and you stop all executing then even the pilot no longer has 
 control of the plane anymore, which would be very bad.


I can't even read the rest of posting after this.

Please read the following articles, then come back.

Assertions in Production Code
https://www.digitalmars.com/articles/b14.html

Safe Systems from Unreliable Parts
https://www.digitalmars.com/articles/b39.html

Designing Safe Software Systems Part 2
https://www.digitalmars.com/articles/b40.html
Aug 31 2018
parent reply tide <tide tide.tide> writes:
On Friday, 31 August 2018 at 22:27:47 UTC, Walter Bright wrote:

 On 8/31/2018 2:21 PM, tide wrote:

 On Friday, 31 August 2018 at 19:50:20 UTC, Walter Bright wrote:

 "Stopping all executing may not be the correct 'safe state' 
 for an airplane though!"


 Depends on the aircraft and how it is implemented. If you have 
 a plane that is fly by wire, and you stop all executing then 
 even the pilot no longer has control of the plane anymore, 
 which would be very bad.


 I can't even read the rest of posting after this.

 Please read the following articles, then come back.

 Assertions in Production Code
 https://www.digitalmars.com/articles/b14.html

 Safe Systems from Unreliable Parts
 https://www.digitalmars.com/articles/b39.html

 Designing Safe Software Systems Part 2
 https://www.digitalmars.com/articles/b40.html


I've already read them before. Why don't you explain what is 
wrong with it rather than posting articles. You are just taking 
one line comments without even thinking about the context.
Aug 31 2018
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/31/2018 5:47 PM, tide wrote:

 I've already read them before. Why don't you explain what is wrong with it 
 rather than posting articles.


Because the articles explain the issues at length. Explaining why your proposal 
is deeply flawed was the entire purpose I wrote them.



 You are just taking one line comments without even 
 thinking about the context.


We can start with the observation that a fly-by-wire is not a fundamentally 
different system than a fully powered hydraulic system or even a pilot muscle 
cable system, when we're talking about safety principles.

There's nothing magic about software. It's just more complicated (a fact that 
makes it even MORE important to adhere to sound principles, not throw them out 
the window).
Sep 01 2018
parent reply tide <tide tide.tide> writes:
On Saturday, 1 September 2018 at 08:05:58 UTC, Walter Bright 
wrote:

 On 8/31/2018 5:47 PM, tide wrote:

 I've already read them before. Why don't you explain what is 
 wrong with it rather than posting articles.


 Because the articles explain the issues at length. Explaining 
 why your proposal is deeply flawed was the entire purpose I 
 wrote them.


I didn't write a proposal. I was explaining a flaw in your 
proposal.


 You are just taking one line comments without even thinking 
 about the context.


 We can start with the observation that a fly-by-wire is not a 
 fundamentally different system than a fully powered hydraulic 
 system or even a pilot muscle cable system, when we're talking 
 about safety principles.


It is vastly different, do you know what fly by wire is? It means 
the computer is taking input digitally and applying the commands 
from the digital input into actual output. If the system 
controlling that just stops working, how do you expect the pilot 
to fly the plane? While all they are doing is moving a digital 
sensor that is doing nothing because the system that reads it 
input hit an assert.


 There's nothing magic about software. It's just more 
 complicated (a fact that makes it even MORE important to adhere 
 to sound principles, not throw them out the window).


I didn't say to throw them the door, I'm saying there's a lot of 
different ways to do things. And using asserts isn't the one ring 
to rule all safety measures. There are different methods, and 
depending on the application, as with anything, has it's pros and 
cons where a different method will be more suitable.
Sep 01 2018
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/1/2018 5:33 AM, tide wrote:

 It is vastly different, do you know what fly by wire is?


Yes, I do. Do you know I worked for three years on critical flight controls 
systems at Boeing? I said so in the article(s). These ideas are not mine, I did 
not come up with them in 5 minutes at the keyboard. They're central to the 
aerospace design industry, and their fantastic safety record is testament to
how 
effective they are.



 If the system controlling that just stops working, how do you 
 expect the pilot to fly the plane?


https://www.digitalmars.com/articles/b40.html

May I draw your attention back to the "Dual Path" section.

Fly by wire failures are no different in principle from a total hydraulic
system 
failure on a fully powered flight control system.

Airliners do suffer total hydraulic failures now and then, despite being unable 
to fly without hydraulics, yet land safely. I'll give you one guess how that is 
done :-) I can give you a brief rundown on how it works after you guess.
Sep 01 2018
prev sibling next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, August 31, 2018 5:20:08 PM MDT H. S. Teoh via Digitalmars-d 
wrote:

 A consequence of this disconnect is that the incentives are set up all
 wrong.  Professors are paid to publish research papers, not to teach
 students.  Teaching is often viewed as an undesired additional burden
 you're obligated to carry out, a chore that you just want to get over
 with in the fastest, easiest possible way, so that you can go back to
 doing research.  After all, it's the research that will win you the
 grants, not the fact that you won teaching awards 3 years in a row, or
 that your students wrote a glowing review of your lectures. So the
 quality of teaching already suffers.


The are plenty of cases where the teachers actually do an excellent job
teaching the material that the courses cover. It's just that the material is
often about theoretical computer science - and this is actually stuff that
can be very beneficial to becoming an excellent programmer. However, many
teachers really aren't great programmers. They aren't necessarily bad
programmers, but unless they spent a bunch of time in industry before
teaching, odds are that they don't have all of the software engineering
skills that the students are going to need once they get into the field. And
most courses aren't designed to teach students the practical skills. How
that goes exactly depends on the school, with some schools actually trying
to integrate software engineering stuff, but many really don't. So, even if
the schools do an excellent job teaching what they're trying to teach, it
still tends to be on the theoretical side of things. But that may be
improving. Still, the theoretical side is something that programmers should
be learning. It's just that it isn't enough on its own, and it serves more
as a good foundation than as the set of skills that you're going to be using
directly on the job on a day to day basis.

The school I went to (Cal Poly, San Luis Obispo) at least tries to focus on
the practical side of things (their motto is "learn by doing"), and when I
went there, they even specifically had a Software Engineering degree where
you had to take a year-long course where you did a project in a team for a
company. But at least at the time, the big difference between the SE and CS
degrees was that they required more classes with group work and fewer
theoretical classes, and there certainly weren't any classes on something
like debugging. The software engineering-centric classes focused more on a
combination of teaching stuff like classic design patterns and then having
you do projects in groups. And that was helpful, but it still didn't really
prepare you for what you were going to be doing in your full-time job. It's
still better than what a lot of schools do though. I'm frequently shocked by
how little many CS graduates know when they first get out of school.

- Jonathan M Davis
Aug 31 2018
next sibling parent RhyS <sale rhysoft.com> writes:
On Friday, 31 August 2018 at 23:47:40 UTC, Jonathan M Davis wrote:

 The are plenty of cases where the teachers actually do an 
 excellent job teaching the material that the courses cover. 
 It's just that the material is often about theoretical computer 
 science - and this is actually stuff that can be very 
 beneficial to becoming an excellent programmer. However, many 
 teachers really aren't great programmers. They aren't 
 necessarily bad programmers, but unless they spent a bunch of 
 time in industry before teaching, odds are that they don't have 
 all of the software engineering skills that the students are 
 going to need once they get into the field. And most courses 
 aren't designed to teach students the practical skills.


Imagine getting a Industrial Engineer that switched over to 
become a teacher, showing up to teach Visual Basic and Database 
normalization.

That same teacher used one of those red little VB books for his 
study material ( been 20+ years ago, not sure if they still exist 
).

The students ended up helping each other fixing issues because 
the teacher was useless. It was even so bad, he took examples out 
of the book, little bit reformatted the questions and used that 
for tests. Of course one of our fellow students figure this out, 
he got his hands on the book and voila, every test answer.

Worst was that the teacher was so BORING, that nobody wanted to 
sit in the front of the class, because his database class was so 
bad, people literally needed to keep each other up from falling 
asleep. I am not joking!

You can guess that i never learned database normalization in 
school and ended up doing it on my own. So yea, first hand 
experience with bad teachers.

The guy that did C++ was way better and you actually learned from 
him. A bit scary guy but knew his stuff. Teachers make all the 
difference for children/students to learn anything.

If they are boring, burned out or just doing it to earn money, it 
shows in the lacking responds and score of the students. A good 
teacher draws in the students and helps them focus. A good 
teacher does not make things over complicated and does not assume 
that everybody understand. Seen brilliant teachers that are 
horrible at teaching because they are so smart ( or repeated the 
same material so much ), they assume everybody understands 
everything as they do.

Teacher make all the difference in teaching but a lot is so 
politicizes/internal power games, ... that good teachers tend to 
leave and bad ones just end up doing the job, because its a good 
government/public servant job with nice vacation perks ( here in 
the EU ).
Aug 31 2018
prev sibling next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
It all comes down to, not enough time to cover the material.

Programming is the largest scientific field in existence. It has merged 
material from Physics, Chemistry, Psychology (in a BIG WAY), Biology, 
you name it and that ignores Mathematics.

Three to four years is just scratching the surface of what is needed to 
be known. There is simply no way to ignore that fact.
Aug 31 2018
parent Paulo Pinto <pjmlp progtools.org> writes:
On Saturday, 1 September 2018 at 05:57:06 UTC, rikki cattermole 
wrote:

 It all comes down to, not enough time to cover the material.

 Programming is the largest scientific field in existence. It 
 has merged material from Physics, Chemistry, Psychology (in a 
 BIG WAY), Biology, you name it and that ignores Mathematics.

 Three to four years is just scratching the surface of what is 
 needed to be known. There is simply no way to ignore that fact.


In many European countries it is 5 years for an engineering 
degree and 3 for polytechnic.

Then you had 2 years for Msc and up to 3 for Phd.

As of the EU normalization (Bologna), the 5 year degrees became a 
Msc one, because there were a few countries were a degree would 
take 3 years.

So on the countries where an engineering degree used to take 5 
years, the universities started pushing for what they call 
"integrated Msc", meaning the same contents before Bologna, but 
with Msc title at the end.
Sep 01 2018
prev sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 08/31/2018 07:47 PM, Jonathan M Davis wrote:

 
 However, many
 teachers really aren't great programmers. They aren't necessarily bad
 programmers, but unless they spent a bunch of time in industry before
 teaching, odds are that they don't have all of the software engineering
 skills that the students are going to need once they get into the field. And
 most courses aren't designed to teach students the practical skills.


This is why we really should bring back the ancient practice of 
apprenticeship, that we've mostly gotten away from.

Doesn't have to be identical to the old system in every detail, but who 
better to teach XYZ to members a new generation than those who ARE 
experts at XYZ.

Sure, teaching in and of itself is a skill, and not every domain expert 
is a good teacher. But like any skill, it can be learned. And after all: 
Who really stands a better chance at passing on expertise?:

A. Someone who already has the expertise, but isn't an expert in teaching.

B. Someone who is an expert at teaching, but doesn't posses what's being 
taught anyway.

Hint: No matter how good of a teacher you are, you can't teach what you 
don't know.

Heck, if all else fails, pair up domain experts WITH teaching experts! 
No need for any jacks-of-all-trades: When people become domain experts, 
just "apprentice" them in a secondary skill: Teaching their domain.

Sounds a heck of a lot better to me than the ridiculous current strategy 
of: Separate the entire population into "theory" (ie, Academia) and 
"practical" (ie, Industry) even though it's obvious that the 
*combination* of theory and practical is essential for any good work on 
either side. Have only the "theory" people do all the teaching for the 
next generation of BOTH "theory" and "practical" folks. Students then 
gain the "practical" side from...what, the freaking ether???? From the 
industry which doesn't care about quality, only profit??? From the 
"theory" folk that are never taught the "practical"??? From where, out 
of a magical freaking hat?!?!?
Sep 01 2018
parent Laeeth Isharc <Laeeth laeeth.com> writes:
On Sunday, 2 September 2018 at 06:25:47 UTC, Nick Sabalausky 
(Abscissa) wrote:

 On 08/31/2018 07:47 PM, Jonathan M Davis wrote:

 
 However, many
 teachers really aren't great programmers. They aren't 
 necessarily bad
 programmers, but unless they spent a bunch of time in industry 
 before
 teaching, odds are that they don't have all of the software 
 engineering
 skills that the students are going to need once they get into 
 the field. And
 most courses aren't designed to teach students the practical 
 skills.


 This is why we really should bring back the ancient practice of 
 apprenticeship, that we've mostly gotten away from.

 Doesn't have to be identical to the old system in every detail, 
 but who better to teach XYZ to members a new generation than 
 those who ARE experts at XYZ.

 Sure, teaching in and of itself is a skill, and not every 
 domain expert is a good teacher. But like any skill, it can be 
 learned. And after all: Who really stands a better chance at 
 passing on expertise?:

 A. Someone who already has the expertise, but isn't an expert 
 in teaching.

 B. Someone who is an expert at teaching, but doesn't posses 
 what's being taught anyway.

 Hint: No matter how good of a teacher you are, you can't teach 
 what you don't know.

 Heck, if all else fails, pair up domain experts WITH teaching 
 experts! No need for any jacks-of-all-trades: When people 
 become domain experts, just "apprentice" them in a secondary 
 skill: Teaching their domain.

 Sounds a heck of a lot better to me than the ridiculous current 
 strategy of: Separate the entire population into "theory" (ie, 
 Academia) and "practical" (ie, Industry) even though it's 
 obvious that the *combination* of theory and practical is 
 essential for any good work on either side. Have only the 
 "theory" people do all the teaching for the next generation of 
 BOTH "theory" and "practical" folks. Students then gain the 
 "practical" side from...what, the freaking ether???? From the 
 industry which doesn't care about quality, only profit??? From 
 the "theory" folk that are never taught the "practical"??? From 
 where, out of a magical freaking hat?!?!?


I agree.  I have been arguing the same for a few years now.

https://www.quora.com/With-6-million-job-openings-in-the-US-why-are-people-complaining-that-there-are-no-jobs-available/answer/Laeeth-Isharc?srid=7h

We de-emphasized degrees and those are information only unless 
for work permits it is a factor (and sadly it is) and also are 
open to hiring people with less vocationally relevant degrees.  A 
recent hire I made was a chap who studied music at Oxford and 
played the organ around the corner.  His boss is a Fellow in 
Maths at Trinity College, Cambridge and us very happy with him.

And we started hiring apprentices ourselves.  The proximate 
trigger for me to make it happen was a frustrating set of 
interviews with more career-oriented people from banks for a 
support role in London.  "Is it really asking too much to expect 
that somebody who works on computers should actually like playing 
with them ?"

So we went to a technical college nearby where someone in the 
group lives and we made a start this year and in time it will 
grow.

The government introduced an apprenticeship programme.  I don't 
think many people use it yet because it's not adapted to 
commercial factors.  But anything new is bad in the first version 
and it will get better.
Sep 02 2018
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Aug 31, 2018 at 05:47:40PM -0600, Jonathan M Davis via Digitalmars-d
wrote:
[...]

 The school I went to (Cal Poly, San Luis Obispo) at least tries to
 focus on the practical side of things (their motto is "learn by
 doing"), and when I went there, they even specifically had a Software
 Engineering degree where you had to take a year-long course where you
 did a project in a team for a company. But at least at the time, the
 big difference between the SE and CS degrees was that they required
 more classes with group work and fewer theoretical classes, and there
 certainly weren't any classes on something like debugging. The
 software engineering-centric classes focused more on a combination of
 teaching stuff like classic design patterns and then having you do
 projects in groups. And that was helpful, but it still didn't really
 prepare you for what you were going to be doing in your full-time job.
 It's still better than what a lot of schools do though. I'm frequently
 shocked by how little many CS graduates know when they first get out
 of school.


[...]

I suppose it depends on the school.  And yes, I've seen CS graduates who
have literally never written a program longer than 1 page.  I cannot
imagine what kind of shock they must have felt upon getting a job in the
industry and being faced, on their first day, with a 2 million LOC
codebase riddled with hacks, last-minute-rushed fixes, legacy code that
nobody understands anymore, inconsistent / non-existent documentation,
and being tasked with fixing a bug of unclear description and unknown
root cause which could be literally *anywhere* in those 2 million LOC.

I was lucky that I was spared of most of the shock due to having spent a
lot of time working on personal projects while at school, and thereby
picking up many practical debugging skills.


T

-- 
Real men don't take backups. They put their source on a public FTP-server and
let the world mirror it. -- Linus Torvalds
Aug 31 2018
prev sibling next sibling parent reply Everlast <Everlast For.Ever> writes:
On Friday, 31 August 2018 at 19:50:20 UTC, Walter Bright wrote:

 https://news.ycombinator.com/item?id=17880722

 Typical comments:

 "`assertAndContinue` crashes in dev and logs an error and keeps 
 going in prod. Each time we want to verify a runtime 
 assumption, we decide which type of assert to use. We prefer 
 `assertAndContinue` (and I push for it in code review),"

 "Stopping all executing may not be the correct 'safe state' for 
 an airplane though!"

 "One faction believed you should never intentionally crash the 
 app"

 "One place I worked had a team that was very adamant about not 
 really having much error checking. Not much of any qc process, 
 either. Wait for someone to complain about bad data and 
 respond. Honestly, this worked really well for small, 
 skunkworks type projects that needed to be nimble."

 And on and on. It's unbelievable. The conventional wisdom in 
 software for how to deal with programming bugs simply does not 
 exist.

 Here's the same topic on Reddit with the same awful ideas:

 https://www.reddit.com/r/programming/comments/9bl72d/assertions_in_production_code/

 No wonder that DVD players still hang when you insert a DVD 
 with a scratch on it, and I've had a lot of DVD and Bluray 
 players over the last 20 years. No wonder that malware is 
 everywhere.


It's because programming is done completely wrong. All we do is 
program like it's 1952 all wrapped up in a nice box and bow tie. 
WE should have tools and a compiler design that all work 
interconnected with complete graphical interfaces that aren't 
based in the text gui world(an IDE is just a fancy text editor). 
I'm talking about 3D code representation using graphics so 
projects can be navigated  visually in a dynamic way and many 
other things.

The current programming model is reaching diminishing returns. 
Programs cannot get much more complicated because the environment 
in which they are written cannot support them(complexity != size).

We have amazing tools available to do amazing things but 
programming is still treated like punch cards, just on acid. I'd 
like to get totally away from punch cards.

I total rewrite of all aspects of programming should be done(from 
"object" files(no more, they are not needed, at least not in the 
form they are), the IDE(it should be more like a video game(in 
the sense of graphical use) and provide extensive information and 
debugging support all at a finger tip away), from the tools, to 
the design of applications, etc.

One day we will get there...
Sep 01 2018
parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 09/01/2018 03:47 PM, Everlast wrote:

 
 It's because programming is done completely wrong. All we do is program 
 like it's 1952 all wrapped up in a nice box and bow tie. WE should have 
 tools and a compiler design that all work interconnected with complete 
 graphical interfaces that aren't based in the text gui world(an IDE is 
 just a fancy text editor). I'm talking about 3D code representation 
 using graphics so projects can be navigated  visually in a dynamic way 
 and many other things.
 
 The current programming model is reaching diminishing returns. Programs 
 cannot get much more complicated because the environment in which they 
 are written cannot support them(complexity != size).
 
 We have amazing tools available to do amazing things but programming is 
 still treated like punch cards, just on acid. I'd like to get totally 
 away from punch cards.
 
 I total rewrite of all aspects of programming should be done(from 
 "object" files(no more, they are not needed, at least not in the form 
 they are), the IDE(it should be more like a video game(in the sense of 
 graphical use) and provide extensive information and debugging support 
 all at a finger tip away), from the tools, to the design of 
 applications, etc.
 
 One day we will get there...
 


GUI programming has been attempted a lot. (See Scratch for one of the 
latest, possibly most successful attempts). But there are real, 
practical reasons it's never made significant in-roads (yet).

There are really two main, but largely independent, aspects to what 
you're describing: Visual representation, and physical interface:

A. Visual representation:
-------------------------

By visual representation, I mean "some kind of text, or UML-ish 
diagrams, or 3D environment, etc".

What's important to keep in mind here is: The *fundamental concepts* 
involved in programming are inherently abstract, and thus equally 
applicable to whatever visual representation is used.

If you're going to make a diagram-based or VR-based programming tool, it 
will still be using the same fundamental concepts that are already 
established in text-based programming: Imperative loops, conditionals 
and variables. Functional/declarative immutability, purity and 
high-order funcs. Encapsulation. Pipelines (like ranges). Etc. And 
indeed, all GUI based programming tools have worked this way. Because 
how *else* are they going to work?

If what you're really looking for is something that replaces or 
transcends all of those existing, fundamental programming concepts, then 
what you're *really* looking for is a new fundamental programming 
concept, not a visual representation. And ance you DO invent a new 
fundamental programming concept, being abstract, it will again be 
applicable to a variety of possible visual representations.

That said, it is true some concepts may be more readily amenable to 
certain visual representations than others. But, at least for all the 
currently-known concepts, any combination of concept and representation 
can certainly be made to work.

B. Physical interface:
----------------------

By this I mean both actual input devices (keyboards, controllers, 
pointing devices) and also the mappings from their affordances (ie, what 
you can do with them: push button x, tilt stick's axis Y, point, move, 
rotate...) to specific actions taken on the visual representation 
(navigate, modify, etc.)

The mappings, of course, tend to be highly dependant on the visual 
representation (although, theoretically, they don't strictly HAVE to 
be). The devices themselves, less so: For example, many of us use a 
pointing device to help us navigate text. Meanwhile, 3D 
modelers/animators find it's MUCH more efficient to deal with their 3D 
models and environments by including heavy use of the keyboard in their 
workflow instead of *just* a mouse and/or wacom alone.

An important point here, is that using a keyboard has a tendency to be 
much more efficient for a much wider range of interactions than, say, a 
pointing device, like a mouse or touchscreen. There are some things a 
mouse or touchscreen is better at (ie, pointing and learning curve), but 
even on a touchscreen, pointing takes more time than pushing a button 
and is somewhat less composable with additional actions than, again, 
pushing/holding a key on a keyboard.

This means that while pointing, and indeed, direct manipulation in 
general, can be very beneficial in an interface, placing too much 
reliance on it will actually make the user LESS productive.

The result:
-----------

For programming to transcend the current text/language model, *without* 
harming either productivity or programming power (as all attempts so far 
have done), we will first need to invent entirely new high-level 
concepts which are simultaneously both simple/high-level enough AND 
powerful enough to obsolete most of the nitty-gritty lower-level 
concepts we programmers still need to deal with on a regular basis.

And once we do that, those new super-programming concepts (being the 
abstract concepts that they inherently are) will still be independent of 
visual representation. They might finally be sufficiently powerful AND 
simple that they *CAN* be used productively with graphical 
non-text-language representation...but they still will not *require* 
such a graphical representation.

That's why programming is still "stuck" in last century's text-based 
model: Because it's not actually stuck: It still has significant 
deal-winning benefits over newer developments. And that's because, even 
when "newer" does provide improvements, newer still isn't *inherently* 
superior on *all* counts. That's a fact of life that is easily, and 
frequently, forgotten in fast-moving domains.
Sep 02 2018
next sibling parent reply Gambler <fake feather.org.ru> writes:
I have to delete some quoted text to make this manageable.

On 9/2/2018 5:07 PM, Nick Sabalausky (Abscissa) wrote:

 [...]
 GUI programming has been attempted a lot. (See Scratch for one of the
 latest, possibly most successful attempts). But there are real,
 practical reasons it's never made significant in-roads (yet).

 There are really two main, but largely independent, aspects to what
 you're describing: Visual representation, and physical interface:

 A. Visual representation:
 -------------------------

 By visual representation, I mean "some kind of text, or UML-ish
 diagrams, or 3D environment, etc".

 What's important to keep in mind here is: The *fundamental concepts*
 involved in programming are inherently abstract, and thus equally
 applicable to whatever visual representation is used.



 If you're going to make a diagram-based or VR-based programming tool, it
 will still be using the same fundamental concepts that are already
 established in text-based programming: Imperative loops, conditionals
 and variables. Functional/declarative immutability, purity and
 high-order funcs. Encapsulation. Pipelines (like ranges). Etc. And
 indeed, all GUI based programming tools have worked this way. Because
 how *else* are they going to work?>
 If what you're really looking for is something that replaces or
 transcends all of those existing, fundamental programming concepts, then
 what you're *really* looking for is a new fundamental programming
 concept, not a visual representation. And ance you DO invent a new
 fundamental programming concept, being abstract, it will again be
 applicable to a variety of possible visual representations.


Well, there are quite a few programming approaches that bypass the
concepts you've listed. For example, production (rule-based) systems and
agent-oriented programming. I've became interested in stuff like this
recently, because it looks like a legitimate way out of the mess we're
in. Among other things, I found this really interesting Ph.D. thesis
about system called LiveWorld:

http://alumni.media.mit.edu/~mt/thesis/mt-thesis.html

Interesting stuff. I believe it would work very well in VR, if
visualized properly.


 That said, it is true some concepts may be more readily amenable to
 certain visual representations than others. But, at least for all the
 currently-known concepts, any combination of concept and representation
 can certainly be made to work.

 B. Physical interface:
 ----------------------

 By this I mean both actual input devices (keyboards, controllers,
 pointing devices) and also the mappings from their affordances (ie, what
 you can do with them: push button x, tilt stick's axis Y, point, move,
 rotate...) to specific actions taken on the visual representation
 (navigate, modify, etc.)

 The mappings, of course, tend to be highly dependant on the visual
 representation (although, theoretically, they don't strictly HAVE to
 be). The devices themselves, less so: For example, many of us use a
 pointing device to help us navigate text. Meanwhile, 3D
 modelers/animators find it's MUCH more efficient to deal with their 3D
 models and environments by including heavy use of the keyboard in their
 workflow instead of *just* a mouse and/or wacom alone.


That depends on the the editor design. Wings 3D
(http://www.wings3d.com), for example, uses mouse for most operations.
It's done well and it's much easier to get started with than something
like Blender (which I personally hate). Designers use Wings 3D for
serious work and the interface doesn't seem to become a limitation even
for advanced use cases.


 An important point here, is that using a keyboard has a tendency to be
 much more efficient for a much wider range of interactions than, say, a
 pointing device, like a mouse or touchscreen. There are some things a
 mouse or touchscreen is better at (ie, pointing and learning curve), but
 even on a touchscreen, pointing takes more time than pushing a button
 and is somewhat less composable with additional actions than, again,
 pushing/holding a key on a keyboard.>
 This means that while pointing, and indeed, direct manipulation in
 general, can be very beneficial in an interface, placing too much
 reliance on it will actually make the user LESS productive.


I don't believe this is necessarily true. It's just that programmers and
designers today are really bad at utilizing the mouse. Most of them
aren't even aware of how the device came to be. They have no idea about
NLS or Doug Engelbart's research.

http://www.dougengelbart.org/firsts/mouse.html

They've never looked at subsequent research by Xerox and Apple.

https://www.youtube.com/watch?v=Cn4vC80Pv6Q

That last video blew my mind when I saw it. Partly because it was the
first time I realized that the five most common UI operations (cut,
copy, paste, undo, redo) have no dedicated keys on the keyboard today,
while similar operation on Xerox Star did. Partly because I finally
understood the underlying idea behind icon-based UIs and realized it's
almost entirely forgotten now. It all ties together. Icons represent
objects. Objects interact through messages. Mouse and command keys allow
you to direct those interactions.

There were other reasons too. That one video is a treasure-trove of
forgotten good ideas.


 The result:
 -----------

 For programming to transcend the current text/language model, *without*
 harming either productivity or programming power (as all attempts so far
 have done), we will first need to invent entirely new high-level
 concepts which are simultaneously both simple/high-level enough AND
 powerful enough to obsolete most of the nitty-gritty lower-level
 concepts we programmers still need to deal with on a regular basis.


That's one other thing worth thinking about. Are we dealing with the
right concepts in the first place? Most of my time as a programmer was
spent integrating badly designed systems. Is that actually necessary? I
don't think so. It's busy-work created by developers for developers.
Maybe better tooling would free up all that time to deal with real-life
problems.

There is this VR game called Fantastic Contraption. Its interface is
light-years ahead of anything else I've seen in VR. The point of the
game is to design animated 3D structures that solve the problem of
traversing various obstacles while moving from point A to point B. Is
that not "real" programming? You make a structure to interact with an
environment to solve a problem.


 And once we do that, those new super-programming concepts (being the
 abstract concepts that they inherently are) will still be independent of
 visual representation. They might finally be sufficiently powerful AND
 simple that they *CAN* be used productively with graphical
 non-text-language representation...but they still will not *require*
 such a graphical representation.

 That's why programming is still "stuck" in last century's text-based
 model: Because it's not actually stuck: It still has significant
 deal-winning benefits over newer developments. And that's because, even
 when "newer" does provide improvements, newer still isn't *inherently*
 superior on *all* counts. That's a fact of life that is easily, and
 frequently, forgotten in fast-moving domains.


Have you seen any of Bret Viktor's talks? He addresses a lot of these
points.

https://vimeo.com/71278954
https://vimeo.com/64895205
https://vimeo.com/97903574
Sep 03 2018
parent Gambler <MyNickname ks2.ru> writes:
On 9/3/2018 1:55 PM, Gambler wrote:

 There is this VR game called Fantastic Contraption. Its interface is
 light-years ahead of anything else I've seen in VR. The point of the
 game is to design animated 3D structures that solve the problem of
 traversing various obstacles while moving from point A to point B. Is
 that not "real" programming? You make a structure to interact with an
 environment to solve a problem.


I posted this without any context, I guess. I brought this game
(http://fantasticcontraption.com) up, because:

1. It's pretty close to "programming" something useful. Sort of virtual
robotics, minus sensors.
2. The interface is intuitive, fluid and fun to use.
3. While you designs may fail, they fail in a predictable manner,
without breaking the world.
4. It's completely alien to all those horrible wire diagram environments.

Seems like we can learn a lot from it when designing future programming
environments.
Sep 03 2018
prev sibling next sibling parent Kagamin <spam here.lot> writes:
On Sunday, 2 September 2018 at 21:07:20 UTC, Nick Sabalausky 
(Abscissa) wrote:

 GUI programming has been attempted a lot. (See Scratch for one 
 of the latest, possibly most successful attempts). But there 
 are real, practical reasons it's never made significant 
 in-roads (yet).

 There are really two main, but largely independent, aspects to 
 what you're describing: Visual representation, and physical 
 interface:

 A. Visual representation:
 -------------------------

 By visual representation, I mean "some kind of text, or UML-ish 
 diagrams, or 3D environment, etc".

 What's important to keep in mind here is: The *fundamental 
 concepts* involved in programming are inherently abstract, and 
 thus equally applicable to whatever visual representation is 
 used.

 If you're going to make a diagram-based or VR-based programming 
 tool, it will still be using the same fundamental concepts that 
 are already established in text-based programming: Imperative 
 loops, conditionals and variables. Functional/declarative 
 immutability, purity and high-order funcs. Encapsulation. 
 Pipelines (like ranges). Etc. And indeed, all GUI based 
 programming tools have worked this way. Because how *else* are 
 they going to work?


They say the main difficulty for non-programmers is control flow, 
not type system, one system was reported usable where control 
flow was represented visually, but sequential statements were 
left as plain C. E.g. we have a system administrator here who has 
no problem with powershell, but has absolutely no idea how to 



 B. Physical interface:
 ----------------------

 By this I mean both actual input devices (keyboards, 
 controllers, pointing devices) and also the mappings from their 
 affordances (ie, what you can do with them: push button x, tilt 
 stick's axis Y, point, move, rotate...) to specific actions 
 taken on the visual representation (navigate, modify, etc.)


Hardware engineers are like the primary target audience for 
visual programming :)
https://en.wikipedia.org/wiki/Labview
Sep 04 2018
prev sibling parent reply Kagamin <spam here.lot> writes:
On Sunday, 2 September 2018 at 21:07:20 UTC, Nick Sabalausky 
(Abscissa) wrote:

 B. Physical interface:
 ----------------------

 By this I mean both actual input devices (keyboards, 
 controllers, pointing devices) and also the mappings from their 
 affordances (ie, what you can do with them: push button x, tilt 
 stick's axis Y, point, move, rotate...) to specific actions 
 taken on the visual representation (navigate, modify, etc.)


Also guess why Linux has problems with hardware support even 
though they have all programmers they need who can write pretty 
much anything.
Sep 04 2018
parent Neia Neutuladh <neia ikeran.org> writes:
On Tuesday, 4 September 2018 at 11:21:24 UTC, Kagamin wrote:

 On Sunday, 2 September 2018 at 21:07:20 UTC, Nick Sabalausky 
 (Abscissa) wrote:

 B. Physical interface:
 ----------------------

 By this I mean both actual input devices (keyboards, 
 controllers, pointing devices) and also the mappings from 
 their affordances (ie, what you can do with them: push button 
 x, tilt stick's axis Y, point, move, rotate...) to specific 
 actions taken on the visual representation (navigate, modify, 
 etc.)


 Also guess why Linux has problems with hardware support even 
 though they have all programmers they need who can write pretty 
 much anything.


Because hardware costs money, reverse engineering hardware is a 
specialized discipline, reverse engineering the drivers means you 
need twice as many people and a more rigorous process for license 
reasons, and getting drivers wrong could brick the device, 
requiring you to order another copy?

Because Linux *doesn't* have all that many programmers compared 
to the driver writers for literally every device in existence?
Sep 04 2018
prev sibling next sibling parent reply Gambler <fake feather.org.ru> writes:
On 8/31/2018 3:50 PM, Walter Bright wrote:

 https://news.ycombinator.com/item?id=17880722
 
 Typical comments:
 
 "`assertAndContinue` crashes in dev and logs an error and keeps going in
 prod. Each time we want to verify a runtime assumption, we decide which
 type of assert to use. We prefer `assertAndContinue` (and I push for it
 in code review),"
 
 "Stopping all executing may not be the correct 'safe state' for an
 airplane though!"
 
 "One faction believed you should never intentionally crash the app"
 
 "One place I worked had a team that was very adamant about not really
 having much error checking. Not much of any qc process, either. Wait for
 someone to complain about bad data and respond. Honestly, this worked
 really well for small, skunkworks type projects that needed to be nimble."
 
 And on and on. It's unbelievable. The conventional wisdom in software
 for how to deal with programming bugs simply does not exist.
 
 Here's the same topic on Reddit with the same awful ideas:
 
 https://www.reddit.com/r/programming/comments/9bl72d/assertions_in_production_code/
 
 
 No wonder that DVD players still hang when you insert a DVD with a
 scratch on it, and I've had a lot of DVD and Bluray players over the
 last 20 years. No wonder that malware is everywhere.


All too true.

A while ago I worked for a large financial company.

Many production systems had zero monitoring. A server with networking
issues could continue to misbehave _for hours_ until someone somewhere
noticed thousands of error messages and manually intervened.

There were also very few data quality checks. Databases could have
duplicate records, missing records or obviously inconsistent
information. Most systems just continued to process corrupt data as if
nothing happened, propagating it further and further.

Some crucial infrastructure had no usable data backups.

With all this in mind, you would be surprised to hear how much they
talked about "software quality". It's just that their notion of quality
revolved around having no bugs ever go into production and never
bringing down any systems. There were ever increasing requirements
around unit test coverage, opinionated coding standards and a lot of
paperwork associated with every change.

Needless to say, it didn't work very well, and they had round half a
dozen outages of varying sizes _every day_.

Alan Kay, Joe Armstrong, Jim Coplien - just to name a few famous people
who talked about this issue. It's amazing that so many engineers still
don't get it. I'm inclined to put some blame on the recent TDD movement.
They often to seem stress low-level code perfectionism, while ignoring
high-level architecture and runtime resilience (in other words, system
thinking).
Sep 01 2018
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/1/2018 2:33 PM, Gambler wrote:

 Alan Kay, Joe Armstrong, Jim Coplien - just to name a few famous people
 who talked about this issue. It's amazing that so many engineers still
 don't get it. I'm inclined to put some blame on the recent TDD movement.
 They often to seem stress low-level code perfectionism, while ignoring
 high-level architecture and runtime resilience (in other words, system
 thinking).


Yup. The worst notions in the industry are:

1. We can make this software bug-free by using Fad Technique X.

2. Since our software has no bugs in it, we needn't concern ourselves with what 
happens when it fails.

3. If it does fail, since we have no plan for that due to (2), we must let it 
proceed anyway.

What could possibly go wrong?
Sep 01 2018
prev sibling next sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 08/31/2018 03:50 PM, Walter Bright wrote:

 https://news.ycombinator.com/item?id=17880722
 
 Typical comments:
 
 "`assertAndContinue` crashes in dev and logs an error and keeps going in 
 prod. Each time we want to verify a runtime assumption, we decide which 
 type of assert to use. We prefer `assertAndContinue` (and I push for it 
 in code review),"
 


Yea, that one makes me cringe. I could at least understand "unwind the 
stack 'till you're at least out of this subsystem, and THEN MAYBE 
abort/retry (but not ignore)", though I know you disagree on that. But 
to just...continue as if nothing happened...Ugh. Just reminds me of 
common dynamic scripting language design and why I never liked those 
languages: If the programmer wrote something nonsensical, best to do 
something completely random instead of giving them an error message!



 "Stopping all executing may not be the correct 'safe state' for an 
 airplane though!"


Honestly, comments like this suggest to me someone who's operating under 
the false assumption that "stop all executing" means "permanently stop 
all of the software running on all components of the plane" rather than 
"stop (and possibly restart) one of several redundant versions of one 
particular subsystem". Which suggests they only read comments and not 
the article.

Interestingly, the same user also said:

"Software development often does seem like a struggle between 
reliability/robustness and safety/correctness."

WAT?!

That's like saying, "Speaker design often seems like a struggle between 
loudness versus volume." Each one *requires* the other.

Scary.



 "One faction believed you should never intentionally crash the app"


I can understand how people may naively come to that conclusion: "Duh, 
crashing is bad, so why would you do it intentionally?" But, of course, 
the reasoning is faulty.

There's also the "It depends on your industry/audience. You're talking 
airplanes, but my software isn't critical enough to bother with the same 
principles." I wonder if it might help to remind such people that's 
*exactly* how MS ended up with Windows Me:

This is well-known:

After Win3.11, MS decided that businesses required more reliability from 
their OS than the home users needed. So they split Windows into two 
product lines: WinNT for business (more focus on reliability) and Win95 
for home (speed and features were more important).

Things started out mostly ok. Win95 wasn't quite as reliable as NT, but 
not a gigantic difference, and it was expected. Then Win98...some more 
issues, while NT stayed more or less as-was. Then WinMe hit. BOOM!

By that point, the latest in the WinNT line was "Win2k", which was STILL 
regarded as pretty well stable, so MS did what's probably the smartest 
move they've ever made: Killed off the 9x/Me codebase, added DirectX to 
Win2k and called it "WinXP". And it spent a whole decade widely hailed 
as the first ever home version of Windows to not be horrible.

So yea, I don't care how non-critical you think your software is. If 
it's worth using, then it's important enough.


 And on and on. It's unbelievable. The conventional wisdom in software 
 for how to deal with programming bugs simply does not exist.


In my observation, there doesn't seem to be much conventional wisdom in 
software in general. Everything, no matter how basic or seemingly 
obvious, is up for big, major debate. (Actually, not even restricted to 
programming.)


[From your comment in that thread]

 fill up your system disk to near capacity, then try to run various 


apps and system utilities.

I've had that happen on accident once or twice recently. KDE does NOT 
handle it well: *Everything* immediately either hangs or dies as soon as 
it gains focus. Well, I guess could be worse, but it still really irks 
me: "Seriously, KDE? You can't even DO NOTHING without trying to write 
to the disk? And you, you other app specifically designed for dealing 
with large numbers of large files, why in the world would you attempt to 
write GB+ files without ever checking available space?"

Seriously, nothing in tech ever improves. Every step forward comes with 
a badly-rationalized step back. Things just get shuffled around, rubble 
gets bounced, trends get obsessively chased in circles, and ultimately 
there's little, if any, overall progress. "What Andy giveth, Bill taketh 
away." Replace Andy/Bill with any one of thousands of different 
pairings, it still holds.

And there's no motivation for any of it to change. Capitalism rewards 
those who make more money by selling more flashy garbage that's bad 
enough to create more need for more garbage to deal with the flaws from 
the last round of garbage. It doesn't reward those who make a better 
product that actually reduces need for more. Sometimes something decent 
will come along, and briefly succeed by virtue of being good. But it's 
temporary and inevitably gets killed off by the next positive feedback 
loop of inferiority. Incompetence DRIVES capitalism; competence 
threatens it.
Sep 01 2018
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Saturday, September 1, 2018 9:18:17 PM MDT Nick Sabalausky (Abscissa) via 
Digitalmars-d wrote:

 On 08/31/2018 03:50 PM, Walter Bright wrote:
 [From your comment in that thread]

  > fill up your system disk to near capacity, then try to run various

 apps and system utilities.

 I've had that happen on accident once or twice recently. KDE does NOT
 handle it well: *Everything* immediately either hangs or dies as soon as
 it gains focus. Well, I guess could be worse, but it still really irks
 me: "Seriously, KDE? You can't even DO NOTHING without trying to write
 to the disk? And you, you other app specifically designed for dealing
 with large numbers of large files, why in the world would you attempt to
 write GB+ files without ever checking available space?"


I suspect that if KDE is choking, it's due to issues with files in /tmp,
since they like to use temp files for stuff, and I _think_ that some of it
is using unix sockets, in which case they're using the socket API to talk
between components, and I wouldn't ever expect anyone to check disk space
with that - though I _would_ expect them to check for failed commands and
handling it appropriately, even if the best that they can do is close the
program with a pop-up.

I think that what it ultimately comes down to though is that a lot of
applications treat disk space like they treat memory. You don't usually
check whether you have enough memory. At best, you check whether a
particular memory allocation succeeded and then try to handle it sanely if
it failed. With D, we usually outright kill the program if we fail to
allocate memory - and really, if you're using std.stdio and std.file for all
of your file operations, you'll probably get the same thing, since an
exception would be thrown on write failure, and if you didn't catch it, then
it will kill your program (though if you do catch it, it obviously can vary
considerably what happens). The C APIs on the other hand require that you
check the return value, and some of the C++ APIs require the same. So, if
you're not doing that right, you can quickly get your program into a weird
state if functions that you expect to always succeed start failing.

So honestly, I don't find it at all surprising when an application can't
handle not being able to write to disk. Ideally, it _would_ handle it (even
if it's simply by shutting down, because it can't handle not having enough
disk space), but for most applications, it really is thought of like running
out of memory. So, isn't tested for, and no attempt is made to make it sane.

I would have hoped that something like KDE would have sorted it out by now
given that it's been around long enough that more than one person would have
run into the problem and complained about it, but given that it's a suite of
applications developed in someone's free time, it wouldn't surprise me at
all if the response was to just get more disk space.

Honestly, for some of this stuff, I think that the only way that it's ever
going to work sanely is if extreme failure conditions result in Errors or
Exceptions being thrown, and the program being killed. Most code simply
isn't ever going to be written to handle such situations, and a for a _lot_
of programs, they really can't continue without those resources - which is
presumably, why the way D's GC works is to throw an OutOfMemoryError when it
can't allocate anything. Anything C-based (and plenty of C++-based programs
too) is going to have serious problems though thanks to the fact that C/C++
programs often use APIs where you have to check a return code, and if it's a
function that never fails under normal conditions, most programs aren't
going to check it. Even diligent programmers are bound to miss some of them.

- Jonathan M Davis
Sep 01 2018
next sibling parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 09/02/2018 12:21 AM, Jonathan M Davis wrote:

 
 The C APIs on the other hand require that you
 check the return value, and some of the C++ APIs require the same.


Heh, yea, as horrifically awful as return value errors really are, I 
have to admit, with them, at least it's actually *possible* to handle 
these low-resource situations sanely, instead of D's "not-so-right-thing 
by default" approach of *guaranteeing* that all software under the same 
circumstance just freaks out and runs screaming like KDE.

(Much as I love D, and as much as I believe in "fail fast", the "Error" 
class still irritates me to no end. My usual approach to dealing with it 
is to stick my fingers in my ears and go "La la la la la!!! It doesn't 
affect me!!! There's no such thing as non-Exceptions being thrown!!! La 
la la!!!!". Not exactly a sound engineering principle. If we actually 
HAD the mechanisms Walter advocates for *dealing* with fail-fast 
processes, then I might have a different opinion. But we *don't*, it's 
just code-n-pray for now, and nothing of the sort is even on the most 
pie-in-the-sky roadmap.)



 Honestly, for some of this stuff, I think that the only way that it's ever
 going to work sanely is if extreme failure conditions result in Errors or
 Exceptions being thrown, and the program being killed.


Under current tools and approaches, that is, unfortunately, probably 
very true.

However...


 Most code simply
 isn't ever going to be written to handle such situations,


This is 2018. We all have a freaking Dick Tracy wireless supercomputer, 
that can believably simulate entire connected alternate realities, in 
realtime...in our pockets! Right now!

If we, the collective software development community of 2018, can't get 
far enough off our collective asses and *do something about* (as opposed 
to *completely ignore and never bother even so much as an automated 
test*) something as basic, obvious, *automatable*, and downright 
*timeless* as...not having our software freak out in the absence of 
resources we're not even freaking using...Well, then we, as an entire 
profession...genuinely SU*K. Hard. (And yes, I am definitely including 
myself in that judgement. I'm more than willing to change my 
prehistoric-programmer ways. But implementation-wise there's relevant 
domain experience I lack, so I can't make this all happen by myself, so 
there needs to be some buy-in.)



 Anything C-based (and plenty of C++-based programs
 too) is going to have serious problems though


Well, yea. No mystery or surprise there. Another reason I tend to be a 
bit dismayed at the continued popularity of those languages (not that 
I'm unaware of all the reasons for their continued popularity).
Sep 02 2018
prev sibling parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Sunday, 2 September 2018 at 04:21:44 UTC, Jonathan M Davis 
wrote:

 On Saturday, September 1, 2018 9:18:17 PM MDT Nick Sabalausky 
 (Abscissa) via Digitalmars-d wrote:

 So honestly, I don't find it at all surprising when an 
 application can't handle not being able to write to disk. 
 Ideally, it _would_ handle it (even if it's simply by shutting 
 down, because it can't handle not having enough disk space), 
 but for most applications, it really is thought of like running 
 out of memory. So, isn't tested for, and no attempt is made to 
 make it sane.


One reason why programs using stdio do fail with disk space 
errors is that they don't know that fclose() can be the function 
reporting it, not the fwrite()/fputs()/fprintf(). I can not count 
the number of times I saw things like that:

     FILE *fd = fopen(...,"w");

     if(fwrite(buffer, length, 1)<1) {
       fine error handling
     fclose(fd);

on disk fullness the fwrite might have accepted the data, but 
only the fclose() really flushed the data to disk, only detecting 
the lack of space at that moment.



 Honestly, for some of this stuff, I think that the only way 
 that it's ever going to work sanely is if extreme failure 
 conditions result in Errors or Exceptions being thrown, and the 
 program being killed. Most code simply isn't ever going to be 
 written to handle such situations, and a for a _lot_ of 
 programs, they really can't continue without those resources - 
 which is presumably, why the way D's GC works is to throw an 
 OutOfMemoryError when it can't allocate anything. Anything 
 C-based (and plenty of C++-based programs too) is going to have 
 serious problems though thanks to the fact that C/C++ programs 
 often use APIs where you have to check a return code, and if 
 it's a function that never fails under normal conditions, most 
 programs aren't going to check it. Even diligent programmers 
 are bound to miss some of them.


Indeed, since some of those error checks also differ from OS to 
OS, some cases might detect things in one setting but not in 
others. See my example above, on DOS or if setvbuf() was set to 
NULL it would not possibly happen as the fwrite() would always 
flush() the data to disk and the error condition would be catched 
nearly 99.9999% of times.
Sep 02 2018
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/1/2018 8:18 PM, Nick Sabalausky (Abscissa) wrote:

 [...]


My take on all this is people spend 5 minutes thinking about it and are 
confident they know it all.

A few years back some hacker claimed they'd gotten into the Boeing flight 
control computers via the passenger entertainment system. I don't know the 
disposition of this case, but if true, such coupling of systems is a gigantic 
no-no. Some engineers would have some serious 'splainin to do.
Sep 02 2018
parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 09/02/2018 09:20 PM, Walter Bright wrote:

 On 9/1/2018 8:18 PM, Nick Sabalausky (Abscissa) wrote:

 [...]


 
 My take on all this is people spend 5 minutes thinking about it and are 
 confident they know it all.


Wouldn't it be nice if we COULD do that? :)


 A few years back some hacker claimed they'd gotten into the Boeing 
 flight control computers via the passenger entertainment system. I don't 
 know the disposition of this case, but if true, such coupling of systems 
 is a gigantic no-no. Some engineers would have some serious 'splainin to 
 do.


Wonder if it could've just been a honeypot. (Or just someone who was 
full-of-it.) Although, I'm not sure how much point there would be to a 
honeypot if the systems really were electronically isolated.
Sep 02 2018
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Another example I read on HackerNews today:

"I recall that during their most recent s3 outage Amazon's status page was
green 
across the board, because somehow all the assets that were supposed to be 
displayed when things went wrong were themselves hosted on the thing that was
down."

https://news.ycombinator.com/item?id=17913302

This is just so basic, folks.
Sep 04 2018
parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 09/04/2018 06:35 PM, Walter Bright wrote:

 Another example I read on HackerNews today:
 
 "I recall that during their most recent s3 outage Amazon's status page 
 was green across the board, because somehow all the assets that were 
 supposed to be displayed when things went wrong were themselves hosted 
 on the thing that was down."
 
 https://news.ycombinator.com/item?id=17913302
 
 This is just so basic, folks.


I absolutely hate webmail (and not being able to spin up arbitrary 
amounts of specific-purpose email addresses). So years ago, I added a 
mailserver of my own to my webserver.

I made absolutely certain to use a *gmail* account (much as I hate 
gmail) and not one of my own self-hosted accounts, as my technical 
contact for all my server-related services. It's saved my ass many times.
Sep 04 2018