EEVblog Electronics Community Forum

Products => Computers => Programming => Topic started by: shivajikobardan on December 17, 2021, 09:35:54 am

Title: how to build programming logic?
Post by: shivajikobardan on December 17, 2021, 09:35:54 am

I am computer engineering student(Our curriculum is 80% similar to electronics engineering in our country so you can call me electronics engineering student as well tbh). But this thing is relevant to electronics engineering as well so I am asking it here. I still don't know how to program. I of course can code very tiny tiny programs like prime number etc etc...But I am nowhere near the level of building big programs like using frameworks to make stuffs and so on.

I learnt c, c++ and python and bit of javascript. But all of them were useless. I learnt programming languages and not programming.

I know assebly language coding in 8085 and 8086 microprocessor. I didn't learn 8051 quite well though.

I think this question is relevant to electronics engineering students in my country(Nepal) as most electronics engineering students pursue career in coding like web development. Any way, coding is essential part of electronics engineering, we all know about that.


I am currently learning python. I learnt syntax of python. And I am currently solving codewars problems. I read other person's solutions as well and try to understand at least 5 different solutions to a problem. My logic has improved a bit in programming but I consciously want to know how to improve my logic in programming? What else can I do to improve my logic in programming? Any guidance will be extremely valuable.
Title: Re: how to build programming logic?
Post by: SiliconWizard on December 17, 2021, 05:33:06 pm
I learnt c, c++ and python and bit of javascript. But all of them were useless. I learnt programming languages and not programming.

I think this is a pretty interesting point you have there. I wish more students saw it the way you do!

What else can I do to improve my logic in programming? Any guidance will be extremely valuable.

Learn algorithmics. Read "The Art of Computer Programming" (D. Knuth). Invaluable.
Title: Re: how to build programming logic?
Post by: Siwastaja on December 18, 2021, 12:31:22 pm
Remember that data structures are everything. The code that processes the data, or logic, is only secondary.
Title: Re: how to build programming logic?
Post by: Jan Audio on December 21, 2021, 04:18:29 pm
Did you try make a game ?
The most complicated thing you can do.
Title: Re: how to build programming logic?
Post by: AntiProtonBoy on December 22, 2021, 04:38:54 am
I learnt c, c++ and python and bit of javascript. But all of them were useless. I learnt programming languages and not programming.
Learning how tools work is quite valuable. Now you have to find a purpose to actually use them. The best way to learn programming is by actually doing it. Just write toy programs, like a ray tracer that dumps a rendered image to disk. Ray tracers are a great example, as it forces you to think about data structures, algorithms, interfacing with libraries, memory management, mathematics and you get fun visual results.

Title: Re: how to build programming logic?
Post by: hli on December 22, 2021, 12:35:07 pm
'Advent of code' (https://adventofcode.com/) is also quite nice to learn. The tasks get progressively harder. There is a reddit with discussions about the problems and the possible solutions, which can help in understanding how to solve the problems.

Learning programming is mostly learning problem solving, and learning micro-skills (although the former might just be a case of the former).
For problem solving, you need to learn how to
Micro-skills are what you might call 'tricks of the trade', but are mostly the small skills that help to get things done faster / more efficiently. In term of computer programming these are
I come to think that the problem solving skill is something that you learn quite early in your life, whereas the micro-skills come with experience.
Title: Re: how to build programming logic?
Post by: cfbsoftware on December 23, 2021, 05:10:26 am
I recommend you read some books on the subject. Some classic examples to get started with are:

Programming Pearls by Jon Bentley
Code Complete by Steve McConnell
Title: Re: how to build programming logic?
Post by: Nominal Animal on December 23, 2021, 05:19:23 am
What else can I do to improve my logic in programming?
Learn problem-solving strategies and methods (https://en.wikipedia.org/wiki/Problem_solving#Problem-solving_strategies) in general.

In a very real sense, as a programmer, we describe problem solving strategies and algorithms for a computer to apply.

I've found that the code per se is not nearly as important as the data structures, strategies, and algorithms.
Pay attention to the comments you write.  They should not describe what the code does (because we can read the code itself just fine), but your intent and/or reasoning behind the code.  Commenting and documenting a project is sometimes worth more in the long run that the code itself.

When the logic, the problem solving stategies and algorithms and data structures are known, the code is relatively straightforward to write: the "problem has already been solved".
Title: Re: how to build programming logic?
Post by: Picuino on December 23, 2021, 10:22:17 am
How to Think Like a Computer Scientist with Python 3

Web: https://openbookproject.net/thinkcs/python/english3e

PDF: https://buildmedia.readthedocs.org/media/pdf/howtothink/latest/howtothink.pdf
Title: Re: how to build programming logic?
Post by: Picuino on December 23, 2021, 10:25:26 am
Another book that I would have loved to know when I started learning to code.

Clean Code: A Handbook of Agile Software Craftsmanship
https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 (https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882)

https://enos.itcollege.ee/~jpoial/oop/naited/Clean%20Code.pdf (https://enos.itcollege.ee/~jpoial/oop/naited/Clean%20Code.pdf)
Title: Re: how to build programming logic?
Post by: Jan Audio on December 23, 2021, 05:19:02 pm
the "problem has already been solved".

shivajikobardan needs some problems first.
And to write bad code so next time wont make the same mistake = learning.
Really that code you mention is invisible and makes no sense, is no learning.
shivajikobardan if you hurry you can program good in 10 years,
just like animal code.
Title: Re: how to build programming logic?
Post by: Nominal Animal on December 24, 2021, 01:43:07 am
the "problem has already been solved".
shivajikobardan needs some problems first.
Agreed.  I perhaps worded myself badly, but I meant that choosing the data structures and algorithms, and finding the exact math (equations et cetera) needed, is at the heart of writing programs.  When I create a program, I do not worry about what the code needs to do – because that becomes clear as the solution reveals itself –, but what kind of data structures and algorithms I need.  Since each problem has many different solutions, finding a "good" one, an "efficient" one, is a general problem solution skill.

Thus, finding interesting problems to work on, and working out exactly how (and why choose that particular way) they are solved using programming, is the key.
Knowing a programming language is one step.
Knowing problem-solving methods and techniques, is more important; and in my opinion, is not discussed enough.
Which is why I suggested to learn about problem solving in general – which in itself is an art, I claim, and useful for all programming tasks.

Even as a kid, I personally liked descriptive geometry, especially the math of how 3D objects, surfaces, etc. can be visualised.  That lead me to basic vector algebra, linear algebra, and unit quaternions (or bivectors, whichever you prefer) to describe orientations and rotations.  I'm curious, but I learn things better when I need to apply them to do something.

Visual things are often "more fun" than non-visual things.  So, working out how e.g. graphical user interfaces are properly implemented, and creating a program that interactively draws fractals, can be lots of fun.  The math itself is simple, but the details can be frustrating, because every single pixel in the image has to be separately handled, and you probably need parallel programming (via threads or processes) to keep the user interface responsive while the image is still being generated.

I also like puzzles, and have used e.g. graph analysis to find solutions to puzzles.  Graphs, trees, heaps, and disjoint set data structures have all been very useful to me.  To help me visually see the data structures, my test programs save the structure in the Graphviz DOT language (http://graphviz.org/) (a text language describing graphs) that I then visualize with Graphviz tools, most often dot.

Games are fun, too.  I do believe my first self-designed one was a typical run-and-jump one on Commodore 64, of a runner trying to jump over a hurdle when the space bar was pressed, written in basic.  Not too far from Flappy Bird, really.  One can start with Curses (https://en.wikipedia.org/wiki/Curses_(programming_library)) – or specifically ncursesw (https://invisible-island.net/), which is included in all Linux distributions, and available for all OSes – for text-mode graphics and interactive keyboard input, to make text-mode games like old Nethack.  The w version refers to "wide", which means it uses wide characters and strings, and allows one to use basically all Unicode glyphs (https://home.unicode.org/) in the text interface.  In Linux, it works extremely well.  Then, there are things like SDL (http://libsdl.org/) library, with which one can create "proper" games.  UI toolkits like Qt, GTK+, TkInter, FLTK, and others provide a way to create proper graphical user interface programs in a portable fashion, not tied to a particular operating system like Windows, MacOS, or Linux.

I also like playing with sounds.  One of my favourite programs on my first PC, a Hyundai 80286, was written in Borland Pascal, and used the internal speaker (a single-tone beeper!) on the computer to emulate the sound of a toilet flushing.  I did not set out to create it, just happened on it by accident, then refined it.  Later in life, as part of my computational materials physics background, I delved into molecular visualization and sonification (describing what happens in an atomic simulation by generating descriptive sounds).

Tools are always nice.  One can never have too many tools.  It is useful to know more than one programming language, so that one can implement a tool in the one that makes most sense.  A while ago, as a result of a discussion here at EEVBlog, I created this example FIR filter response analysis page (https://www.nominal-animal.net/answers/fir-analysis.html), as an example of a self-contained HTML+CSS+JavaScript tool, that can be either hosted on the net, or saved to your local computer and used locally without any internet connection.  It is a good example of choosing the proper tool (language/environment), as the entire thing is just 372 lines (most of which is the visual HTML and CSS stuff).  It is not complete, though, as it was only an example of how such things could be done.

Understanding different programming paradigms is very important, though.  For JavaScript on web pages, we use event-driven programming (https://en.wikipedia.org/wiki/Event-driven_programming), because that's how the Document Object Model, the "glue" between HTML and CSS visual description and JavaScript works (https://www.w3schools.com/js/js_htmldom.asp).  Similarly with UI toolkits like Qt and Gtk+.  But for SDL and Curses, we are fully in control, in imperative fashion, of the entire display and refresh loop; as is usual when creating games.

It is not good to specialize early on something.  Working on wildly different things exposes you to more ideas, more models, more paradigms, and therefore more problem solving methods, which are definitely needed when you build your developer career.  Every week, I still use several different programming languages – shell (my choice is usually Bash, but I do sometimes use Dash, a POSIX shell), awk, C, Python; others vary from week to week depending on what I'm working on – and every week, I learn more.  I myself am still learning.  One of the things I wish I had learned better early on, is to write better comments: I still need to work a lot on that.

Making errors is often the most interesting facet, if you take the time to find out what went wrong, and why.  (I absolutely hate the "stick spaghetti to the wall, and see what sticks" attitude, when someone says that "this fixed it, but I don't know why".  To me, it feels like reading a detective story that ends with somebody going to jail but no evidence presented that they were actually the perpetrator.  Unsatisfying.)  I suspect that the most interesting things I know, I learned by making errors.  It is uncomfortable and sometimes painful to err, definitely, but it just makes the satisfaction of solving the problem or completing the work so much more rewarding in the end.

If your personal path is different, don't worry: most paths differ.  Just enjoy every step of the way, because the path itself is the purpose and end goal.  You are never "done" or "finished learning": there is always something new to discover, learn, invent, solve, or ask.

Oh, and apologies for the wall of text.  My excessive verbosity is another thing I'm still working on. :)
Title: Re: how to build programming logic?
Post by: brucehoult on December 24, 2021, 04:36:07 am
On a small scale, learn how to design loops that work and are not buggy. Learn about preconditions and postconditions and loop invariants and weakest-preconditions. A lot of academic work was done around this 40 years ago. Learn how to use recursion well. Contrary to popular belief, it is easier to reason about and prove recursion than iteration.

Learn how the structure of code matches the structure of the data. Wirth's book "Data Structures + Programs = Algorithms" is still worth reading.

Although it was designed for COBOL and business applications in the days of punched cards and magnetic tapes, Michael A. Jackson's "Jackson Structured Programming" has some interesting and useful insights into how to constructively design your program structure based on the (maybe complex) structure of the data it processes. It is still useful today for thinking about programs that deal with files, network streams, structuring multiple programs or threads that communicate via FIFOs etc. https://en.wikipedia.org/wiki/Jackson_structured_programming

Title: Re: how to build programming logic?
Post by: DiTBho on December 24, 2021, 01:57:15 pm
I learned c, c++ [...] I learned programming languages and not programming.

I can say, after ~25 years of experience as a paid engineer, I still don't know *how to program*, I only know *how to solve some problems*, not all kinds of problems, only a few classes of problems.

Title: Re: how to build programming logic?
Post by: RoGeorge on December 24, 2021, 02:22:12 pm
I learnt c, c++ and python and bit of javascript. But all of them were useless. I learnt programming languages and not programming.
...
I am currently learning python. I learnt syntax of python. And I am currently solving codewars problems. I read other person's solutions as well and try to understand at least 5 different solutions to a problem. My logic has improved a bit in programming but I consciously want to know how to improve my logic in programming? What else can I do to improve my logic in programming? Any guidance will be extremely valuable.

Also, from a hardware perspective and related to the "programming logic" words you mentioned in the title, you may want to read about "state machines".  Often, State Machines are rather neglected in software/programming-like classes.  I've only noticed "state machines" theory as important only very late, when starting to fool around with FPGAs.

Now I think State Machines should be stressed more while learning software.  It is very unfair that State Machines is often taken lightly in software, and studied deeper only when it came to digital-design/FPGAs/hardware topics.

You mentioned Nepal, but I think such "programming" pitfalls are everywhere.  Though, I'm not a software developer, I'm from the hardware side, so I might be all wrong talking about software.

Not sure how much might help, there is a YouTube channel from a dude that put State Machines in the center of his attention, mostly presented as ARM programming classes, but he developed a State Machines based programming tools and style:
https://www.youtube.com/channel/UCMGXFEew8I6gzjg3tWen4Gw (https://www.youtube.com/channel/UCMGXFEew8I6gzjg3tWen4Gw)
Title: Re: how to build programming logic?
Post by: bobcat2000 on December 26, 2021, 08:53:13 pm
Quote
My logic has improved a bit in programming but I consciously want to know how to improve my logic in programming? What else can I do to improve my logic in programming?

I think you are taking the wrong classes.  If I remember correctly when I was in school, my programming classes taught very little programming.  Majority of the classes taught math.  LOT OF MATH.  My homework were full of Calculus calculations.  Networking classes were nothing but math.  AI classes were math.  Programming were even more math.

So, I think the school has already figured out how to "improve your logic in programming".  MATH!!!

P.S. Hey! I got an A in this project ;)

 
Title: Re: how to build programming logic?
Post by: rstofer on December 26, 2021, 09:50:10 pm

Learn how the structure of code matches the structure of the data. Wirth's book "Data Structures + Programs = Algorithms" is still worth reading.


That is my all-time favorite book and Pascal will always be my favorite language.

The PL0 tiny pascal compiler/run time in the back of the book is excellent and demonstrates many of the ideas previously presented.  I have coded that thing a half dozen times since I started with UCSD Pascal back around '80 or so.  I also translated the code to Fortran.  Pascal took 6 pages, Fortran took 54 pages.  Now, I'll concede the Fortran interpretation was crap but, really, sets aren't much fun in Fortran and that compiler project uses set operations all over the place.

In the end, programming is about the data more than the code.  How data comes in, what data is coming, how is the program to respond to the data and what should it output.  If you get the data structures right, selecting algorithms and writing code is fairly straightforward.  If the data structures are wrong, you will forever be putting lipstick on a pig.

One thing that Wirth points out in the book is the inadvertent use of null pointers.  Over and over, he shows how to make the mistake and how to prevent it.  C programmers are notorious for trying to reference through a null pointer but I suppose it is common to other languages as well.  Just something to keep in mind when using linked lists.

One of the problems I have with learning new languages is that the book authors show little ideas but there is no overarching project.  I would really like to see a book on C++ that starts with the definition of a fairly large project and works up the code, piece by piece.  It needs to be a large enough project to use all of the language features that are described in the book.  I'm thinking about 10,000 lines or so of something that could be useful.

I realize this is a great deal more difficult than simply writing about classes in the abstract.  Here's a class, here's the member functions, here's the public and private data; this is all pretty easy.  But it simply doesn't tie anything together.

Title: Re: how to build programming logic?
Post by: SiliconWizard on December 26, 2021, 10:18:33 pm
In the end, programming is about the data more than the code.  How data comes in, what data is coming, how is the program to respond to the data and what should it output.  If you get the data structures right, selecting algorithms and writing code is fairly straightforward.  If the data structures are wrong, you will forever be putting lipstick on a pig.

Since the "computing world" is notorious for running in circles, you won't be surprised to know that "data-oriented programming" is now depicted as the new shiny paradigm, while it was already known decades ago.
Title: Re: how to build programming logic?
Post by: DiTBho on December 27, 2021, 11:13:18 am
In the end, programming is about the data more than the code.  How data comes in, what data is coming, how is the program to respond to the data and what should it output.  If you get the data structures right, selecting algorithms and writing code is fairly straightforward.

That's what(Software) Design is for, a process to transform user requirements and constraints into some suitable form, which helps the programmer in software coding and implementation.

design ( requirements, constraints ) -> { programming -> coding -> { implementation, testing } }

Quote
If the data structures are wrong, you will forever be putting lipstick on a pig

I love this expression  ;D ;D ;D
Title: Re: how to build programming logic?
Post by: Jan Audio on December 27, 2021, 03:56:45 pm
Basicly what they say at the university here : You have internet go find out how it works.
Title: Re: how to build programming logic?
Post by: emece67 on December 27, 2021, 04:45:52 pm
.
Title: Re: how to build programming logic?
Post by: MarkMLl on December 29, 2021, 01:57:38 pm
I learnt programming languages and not programming.

If you already realise that, then you've learnt more than most "experienced professionals".

Apart from the excellent points being made by everybody else, I always maintain that a reasonable command of computer hardware and architecture is an enormous aid to understanding software, and a reasonable command of software engineering is an enormous aid to understanding hardware. It's most unfortunate that most curriculums keep the disciplines separate and turn out graduates with deep proficiency in one language or technique rather than adaptable generalists.

But because software tools, documentation and papers are more readily accessible than large-scale hardware design and testing tools, it's arguably easier for a competent engineer to develop software skills than for a programmer to achieve competence in hardware.

MarkMLl
Title: Re: how to build programming logic?
Post by: SiliconWizard on December 29, 2021, 06:12:41 pm
Basicly what they say at the university here : You have internet go find out how it works.

Oh yeah? So what is the university good for? Just deliver a degree? If so, I bet it could be done for much cheaper. :popcorn:
Title: Re: how to build programming logic?
Post by: Jan Audio on December 30, 2021, 01:38:13 pm
Indeed you need the paper to get work mostly, not some working code.
I just like to say they cant help it either things go very fast, they cant offer you.

I stuck with my C++ and C thingie so i learned it, the university should also stay with something,
only it is easy to get distracted by other things, because internet is so big they want shit like java or safe languages that dont work fast,
and more modern things in the future also keep distracting because they dont know what to choose, logically.

Then you have the updates.
Creating a study cost about 10 years i heard, in 10 years its all outdated.
Note : i a have windows XP system, cant ask that from your students because microsoft say windows xp is a big virus.
Title: Re: how to build programming logic?
Post by: rstofer on December 30, 2021, 05:45:48 pm
Does anybody use flowcharts anymore?  They were a big deal in the early '70s when I started programming and could be quite detailed.  IBM documentation often included machine printed flowcharts.

I still scribble them down from time to time depending on the complexity of the function I am writing.
Title: Re: how to build programming logic?
Post by: bobcat2000 on December 30, 2021, 08:21:51 pm
Whhaaa!!!  Flowchart you say????   :-DD

You are lucky to see a single line of comment in the codes nowadays.  No CRC. No chart of any kind.  No Programming Standard.  No specs written.

Companies subcontract the programming oversea.  You try to tell the guy what you want to do and hope he can understand.  The codes come back and you are like WTF.

The last thing and the only thing I saw was a very big ER diagram from a big corporation.  The IT manager printed them all out and taped the printouts like wall paper covering the 4 walls of the entire office.  For the other companies, they just want to get their things done.  No chart no note no nothing.  They don't care.

So, go take some upper division classes from school.  The classes will teach you a lot of techniques to improve your programming logic.

Title: Re: how to build programming logic?
Post by: SiliconWizard on December 30, 2021, 08:36:30 pm
In the old days - like, up to the 90s or so - people were actually analyzing before programming. That was actually a real  job. Nowadays, you don't, and specifying, analyzing and programming are pretty much all mixed up (except in niche fields - safety critical stuff - and even so, specifying is then a separate job indeed, but "analyzing" vs. "programming", per se, is not really anymore.)

Thank cost reduction and the agile fad. Writing specs has become an insult. Analyzing, defining architectures before coding? You bet your ass not. It's so inflexible and so unproductive (so they claim.) You code, code, code away, write lame tests with pieces of your own code too, and move on (so basically, your tests prove that your code is your code is your code.) Who cares anymore about programming logic? If you don't know how to do something, just use a library. If you're not even quite sure what it is your code is supposed to do, you don't really care. There are no specs. :-DD
Title: Re: how to build programming logic?
Post by: MarkMLl on December 30, 2021, 09:06:30 pm
Does anybody use flowcharts anymore?  They were a big deal in the early '70s when I started programming and could be quite detailed.  IBM documentation often included machine printed flowcharts.

I still scribble them down from time to time depending on the complexity of the function I am writing.

Apart from what other people are saying, they were largely obsoleted by Jackson Structured Programming, Unified Modelling Language and the rest. And even when they were popular there were alternatives, e.g. one promoted by Dijkstra.

I was dealing with a particularly complex startup sequence in some embedded code in about '93, and drew a flowchart to get to grips with it. And even then I felt I was doing something decidedly... well, I'd have said "retro" but I don't think the word existed in those days :-)

MarkMLl
Title: Re: how to build programming logic?
Post by: rstofer on December 30, 2021, 09:30:16 pm
One of the CS luminaries once declared that programmers shouldn't have access to a keyboard.  The layers have changed and it's probably software designers who shouldn't have keyboards.

From my FORTRAN days I can understand #652.  The best FORTRAN programs were created after the programmer dropped the box of cards.  Today we probably call it 'refactoring'.

https://medium.com/@caldavis/1256-quotes-about-technology-curated-fbe7f8e791cb
Title: Re: how to build programming logic?
Post by: dunkemhigh on December 30, 2021, 09:40:56 pm
Quote
Does anybody use flowcharts anymore?

Kind of. I pretty much always do a state transition diagram for a state machine. Flow charts, not so much but if it makes a non-obvious thing simpler then I will. The thing nowadays is UML (or SYSML for embedded) but you really need to speak it to read it, and a flow chart is understandable without prior training.
Title: Re: how to build programming logic?
Post by: SiliconWizard on December 30, 2021, 09:50:19 pm
Yeah. The UML spec has grown to almost 800 pages.
Title: Re: how to build programming logic?
Post by: MarkMLl on December 30, 2021, 10:06:13 pm
One of the CS luminaries once declared that programmers shouldn't have access to a keyboard.

Can you provide a reference for that? It has the feel of Fred Brooks about it, and many of the things that he said (in The Mythical Man-Month etc.) became perfectly obvious when his rationale was considered.

Without further explanation, I'd suggest that it might parallel the productivity gain seen inside Sun (I think) when Powerpoint presentations were banned: if a programmer doesn't have access to a keyboard then he won't be tempted to tinker endlessly.

MarkMLl
Title: Re: how to build programming logic?
Post by: rstofer on December 31, 2021, 03:22:17 am
One of the CS luminaries once declared that programmers shouldn't have access to a keyboard.

Can you provide a reference for that? It has the feel of Fred Brooks about it, and many of the things that he said (in The Mythical Man-Month etc.) became perfectly obvious when his rationale was considered.

Without further explanation, I'd suggest that it might parallel the productivity gain seen inside Sun (I think) when Powerpoint presentations were banned: if a programmer doesn't have access to a keyboard then he won't be tempted to tinker endlessly.

MarkMLl

I can't remember the author, maybe Dijkstra or Wirth, somebody of that stature.  I haven't seen the quote in more than 20 years and the constext was that programmers should be designing their code with paper and pencil and leaving typing to someone else.

In the early days, we had an entire department full of keypunch operators.  I could never use their services due to budget constraints but I still wrote my code on Fortran Coding Forms - then I keypunched it.
Title: Re: how to build programming logic?
Post by: Nominal Animal on December 31, 2021, 08:17:56 am
If OP was asking career advice, then I'd have recommended self-expression/assertiveness/speaking/image projection course with a professional.

In today's business world, what you actually can do is secondary; the optics are primary.  Dress appropriately (slightly smarter than expected, but without making it obvious), speak the lingo, project an image, and be constantly on the lookout for switching jobs upwards.  Do not stay in one place for longer than three years, absolute maximum; preferably switch jobs just below the two year mark.  Be a people person, but never take any risks in personal relationships: they can backfire, and ruin your career.  Even innocuous help can backfire if the person does something inappropriate, so don't do it.

Be ruthless.  Never explain or admit any errors, just move on.  Take all glory from successes you participated in; which also means you need to choose what you participate in based on their likelihood of success, not on any innate interest.

Personally, I just can't do that shit.  I've chosen to be poor but happy and non-broken.
Title: Re: how to build programming logic?
Post by: brucehoult on December 31, 2021, 08:42:27 am
Personally, I just can't do that shit.  I've chosen to be poor but happy and non-broken.

I was getting worried there for a moment!

Me too.

At least the interesting jobs started to pay better once I got past 45, and I also got to live in or regularly visit interesting foreign places such as Moscow and San Francisco. That seems to have helped get better offers from NZ companies afterwards too -- my disposable salary after taxes, deductions, rent, car insurance, utilities is now better working for a NZ company than it was at SiFive in San Francisco, though not quite as good as at Samsung in Moscow (slightly lower gross salary but low taxes, low rents, nearly free utilities).

Retirement is a worry though. I guess I never will.
Title: Re: how to build programming logic?
Post by: MarkMLl on December 31, 2021, 08:57:10 am
I can't remember the author, maybe Dijkstra or Wirth, somebody of that stature.  I haven't seen the quote in more than 20 years and the constext was that programmers should be designing their code with paper and pencil and leaving typing to someone else.

In the early days, we had an entire department full of keypunch operators.  I could never use their services due to budget constraints but I still wrote my code on Fortran Coding Forms - then I keypunched it.

Wouldn't have been Wirth, he was a hands-on guy. If it were Dijkstra he needs to be taken in context: he was inclined to be /intentionally/ stroppy (his most popular quotes come from his "how do we tell truths that hurt?" paper), and he developed a massive grudge against IBM for- he believed- ignoring the significance of his work.

(You had coding forms? Luxury! We had to toggle in the loader by hand, or load tests from paper tape with the consistency of airgun target.)

MarkMLl
Title: Re: how to build programming logic?
Post by: MarkMLl on December 31, 2021, 02:25:07 pm
I can't remember the author, maybe Dijkstra or Wirth, somebody of that stature.  I haven't seen the quote in more than 20 years and the constext was that programmers should be designing their code with paper and pencil and leaving typing to someone else.
Wouldn't have been Wirth, he was a hands-on guy. If it were Dijkstra he needs to be taken in context: he was inclined to be /intentionally/ stroppy (his most popular quotes come from his "how do we tell truths that hurt?" paper), and he developed a massive grudge against IBM for- he believed- ignoring the significance of his work.

Apropos "a programmer should not use a keyboard": I had a few minutes while the coffee machine came to life...

I think it was an apocryphal story /about/ Dijkstra, based on an apocryphal (and now disproven) story that Mozart composed without a keyboard.

It is contradicted by EWD 279 https://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/EWD279.html (https://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/EWD279.html) where he writes

Quote
As target system I am envisaging a "programming laboratory", as I seem to need this for the education of software engineers.
...
The kind of hardware I am looking for is a simple, very fast machine, with a reasonably sized primary store, a very large backing store, a line printer, a few keyboard terminals
...
The keyboard terminals are viewed as "the programmer's desk". I need at least two of them, to create the environment of parallel interactions (extensions or modifications) with the same program, perhaps an "operators console" in addition to that. If the laboratory grows towards an environment in which larger numbers of students can get experience, more might be needed for reasons of more intense usage of the system.

Mention of an operator's console in that context does not mean that there was a dedicated system operator present. The sort of machines with which Dijkstra was familiar might have supported interactive terminals, but the operation of starting up (and if necessary killing) the interactive subsystem could not necessarily be handled by the terminal itself... and very often a console was needed to e.g. tell the system that a scratch tape had been mounted or in extremis as output for a system memory dump.

I also found this:

Quote
Apart from the two telephones, another notable feature of the office in Dijkstra’s home was an elegant portable Olivetti typewriter. At the time, a proper professor would write with a fountain pen, possibly a Mont Blanc, which was at the time one of several ordinary brands. Only secretaries touched a keyboard. But Edsger typed his EWD memo’s himself, somewhere acknowledging the unversity for purchasing for his sole use the one typewriter with the one font that could do justice to his thoughts. This way he did a lot of typing: the big one, “Notes on Structured Programming” (EWD249), runs to 88 pages.

Fast forward to my visit to Edsger in the 1980s in Austin, Texas, when all profs did their writing on keyboards and Edsger refused to touch one. I have since been told that one way of swearing allegiance to Edsgerismus is to purchase a Mont Blanc and to find that it facilitates the proofs of your programs (which are only to be contemplated, not executed). In his office Edsger had a pencil dangling from a string with a sign pointing to it saying “Word Processor”.

Not only were word processors anathema to Edsger as superfluous mechanical devices, but they also gave offense by coming with fat manuals. Edsger told me indignantly that some manual for Wordperfect ran to six hundred and fifty pages. He reminded me of the fact that Georg Joos only needed six hundred for his great work “Textbook of Theoretical Physics”. It was blasphemy to Edsger that a manual for buggy software for a perverse purpose used more space than a comprehensive compilation of the most sublime knowledge.

https://vanemden.wordpress.com/2008/05/06/i-remember-edsger-dijkstra-1930-2002/ (https://vanemden.wordpress.com/2008/05/06/i-remember-edsger-dijkstra-1930-2002/)

MarkMLl
Title: Re: how to build programming logic?
Post by: rstofer on December 31, 2021, 04:54:41 pm
Interesting history!

When I started using the IBM1130 in 1970, we had 2 machines in an 'open shop'.  Walk up, take complete control of the machine.  There were no operators for these machines other than the users - primarily aerospace engineers (except me...)  Oddly, the keyboard and typewriter weren't used for much beyond playing 3D Tic-Tac-Toe (Robert Louden's IBM 1130 book had the code).

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

In the same room was a CDC 1700 which was a remote terminal for the CDC 6400 up at the mother plant.  That machine had an operator.  Submit your card deck, come back later for the results.

Grad school (circa'75) was a DataGeneral <something> with teletype machines around the campus.  I had dial-up access with a 110 baud acoustic coupler that I eventually upgraded to 300 baud modem.  I had a lot of fun playing Startrek on that machine.  Writing a Tiny Algol compiler in Basic wasn't easy...

There's a reason I built an FPGA incantation of the IBM 1130 that runs all of the factory software, unchanged.
Title: Re: how to build programming logic?
Post by: MarkMLl on December 31, 2021, 06:01:11 pm
Ah yes, the IBM 1130. I ended up writing my own 2741 emulator so I could play around with its APL implementation... then went on to modify it to be useful in a whole lot of other contexts. But since the character encoding etc. was determined by the design of the Selectric mechanism, things like cut-and-paste became /exceptionally/ hairy. I'm not sure whether one should be sneakily proud of something which is so difficult to maintain :-)

In actual fact, the 1130 and competing machines like the LGP-30 (and the Burroughs L and TC electromechanical accounting machines, and a whole lot of other stuff) are part of a "personal computer" tradition that reaches back to ENIAC via Stan Frankel. Arguably, IBM's APL successfully tapped into that tradition: which of course has links to both Wirth (who supervised Breed's early implementation at Stanford) and Dijkstra (who publicly derided both APL and IBM).

MarkMLl
Title: Re: how to build programming logic?
Post by: SiliconWizard on December 31, 2021, 06:43:58 pm
One of the CS luminaries once declared that programmers shouldn't have access to a keyboard.

Can you provide a reference for that? It has the feel of Fred Brooks about it, and many of the things that he said (in The Mythical Man-Month etc.) became perfectly obvious when his rationale was considered.

Without further explanation, I'd suggest that it might parallel the productivity gain seen inside Sun (I think) when Powerpoint presentations were banned: if a programmer doesn't have access to a keyboard then he won't be tempted to tinker endlessly.

MarkMLl

I can't remember the author, maybe Dijkstra or Wirth, somebody of that stature.  I haven't seen the quote in more than 20 years and the constext was that programmers should be designing their code with paper and pencil and leaving typing to someone else.

Yep. I remember this quote too, and can't remember who either. This is congruent with what I said earlier though, that analyzing was a job in itself and separate from programming, and that this was considered good practice.

But even if the same person does both activities, I still think it's good practice, and this is, among other points, why I find trying to fight the alleged "verbosity" of programming languages completely irrelevant - something that most modern programming languages have tried to do, and that a majority (or so it seems) of developers are on board with. As though saving a few keystrokes would make a difference. If you actually design your programs before coding them, it absolutely doesn't. Of course, if you start typing away frantically without any kind of prior analysis, I suppose it would. :popcorn:
Title: Re: how to build programming logic?
Post by: rstofer on December 31, 2021, 07:50:44 pm
Yep. I remember this quote too, and can't remember who either. This is congruent with what I said earlier though, that analyzing was a job in itself and separate from programming, and that this was considered good practice.

But even if the same person does both activities, I still think it's good practice, and this is, among other points, why I find trying to fight the alleged "verbosity" of programming languages completely irrelevant - something that most modern programming languages have tried to do, and that a majority (or so it seems) of developers are on board with. As though saving a few keystrokes would make a difference. If you actually design your programs before coding them, it absolutely doesn't. Of course, if you start typing away frantically without any kind of prior analysis, I suppose it would. :popcorn:

The Bureau of Labor Statistics differentiates programmers from developers

https://www.bls.gov/ooh/computer-and-information-technology/computer-programmers.htm (https://www.bls.gov/ooh/computer-and-information-technology/computer-programmers.htm)
https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm (https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm)

There's quite a difference in pay scale as well as scope of work.

Title: Re: how to build programming logic?
Post by: brucehoult on December 31, 2021, 11:11:13 pm
There's a reason I built an FPGA incantation of the IBM 1130 that runs all of the factory software, unchanged.

In my first year at university (1981) the computer lab for 1st year students had a PDP 11/34 with 256k RAM, 22 VT100 terminals, and 2 LA120 printers.

The year before us (I'd visited a friend who skipped 7th form) they'd used it with an environment where you edited FORTRAN then when you said to RUN it you were forcibly logged off (so someone else could have a go) and you went to the printers to get the result of your compilation and/or run. If it didn't work then you had to fight for a terminal and have another go.

But our year got a different environment. The machine was running a light weight multi user OS (RT11? Not RSTS anyway) with a shell that gave you a few basic DIR, TYPE, PRINT, RENAME, DELETE commands (I think there was *both* COPY and PIP) and a locally-written line editor. The editor code was shared between all users, and you could edit I think a maximum 8k text file (1 MMU segment). Pascal compilation was provided via the NBS (National Bureau of Standards!) Pascal compiler running in a batch queue, so only one compile could actually happen at a time. Later in the year this was changed to the more powerful but slower OMSI Pascal. Once you'd got your program compiled you were free to keep the binary and run it as and when you wanted (subjected to VERY tight disk quota -- you had to reduce to maybe 32 KB before you could log off)

One of the first things I did was write a light weight fell-screen text editor so I didn't have to use the provided line editor. As I recall, I had a doubly-linked list of lines of text, with each line a singly-linked list of records with an array of 6 chars and a (2 byte) pointer to the next chunk. And a free-list of line and char chunk records. The line with the cursor on was copied to an 80 char array. I only implemented typing to insert (including newline), backspace to delete, and arrow keys to move. No copy and paste -- if you wanted large scale rearrangements you could quit and use the provided line editor. It was still a huge improvement over the line editor. I left a world-execute copy in my home directory and told friends about it. I don't remember the executable size now but it was tiny -- and of course shared between multiple people running it.

Oops .. that was a sidetrack. There was a dusty old IBM 1130 in the back corner of the terminal room. I never saw it running. It featured a couple of times in lectures, primarily about the 28 pass FORTRAN compiler. Sad that I didn't get a chance to try it, if it even still worked.
Title: Re: how to build programming logic?
Post by: MarkMLl on January 01, 2022, 08:15:00 am
In my first year at university (1981) the computer lab for 1st year students had a PDP 11/34 with 256k RAM, 22 VT100 terminals, and 2 LA120 printers.

When I went up in '75 we were expected to use card punches for FORTRAN... there was another bank used by maths types for some variant of ALGOL and Teletypes along one wall for the bearded postgrads. By the time I left the cardpunches had been replaced by some variety of terminal, but I believe the overall job cycle was still very similar: enter your program, run it, and come back later for the printout.

One of my lecturers was an engaging chap by the name of David Brailsford :-)

Subsequent to that I worked for a mainframe company which was an interesting experience: they were heavily into automating bank and building society branches with (by our standards) ridiculously underpowered computers giving good response on hundreds of terminals. And I spent a few years at a university where the central computer system was Multics, and there was a jury-rigged system of Kermit and Gandalf boxes hooking things together campus-wide.

MarkMLl
Title: Re: how to build programming logic?
Post by: rstofer on January 01, 2022, 04:02:21 pm
I guess you all realize that we have lived through exciting times.  And continue to do so...
Can you even imagine what the next 50 years will bring?

Title: Re: how to build programming logic?
Post by: MarkMLl on January 01, 2022, 04:18:33 pm
I guess you all realize that we have lived through exciting times.  And continue to do so...
Can you even imagine what the next 50 years will bring?

Yes, "The Limits to Growth" was required reading for one of my courses.

MarkMLl
Title: Re: how to build programming logic?
Post by: brucehoult on January 01, 2022, 09:15:57 pm
I guess you all realize that we have lived through exciting times.  And continue to do so...
Can you even imagine what the next 50 years will bring?

I'm hoping I won't have to imagine the first 1/2 to 2/3 of that!
Title: Re: how to build programming logic?
Post by: brucehoult on January 01, 2022, 09:18:53 pm
I guess you all realize that we have lived through exciting times.  And continue to do so...
Can you even imagine what the next 50 years will bring?

Yes, "The Limits to Growth" was required reading for one of my courses.

Yeah, we had to read that too. And "Future Shock". What total bullshit they both were! The number of times we've supposedly been about to run out of this or that in 5 or 10 years -- starting 40 years ago!

Much better to read Pournelle's "A Step Farther Out" from 1979.
Title: Re: how to build programming logic?
Post by: SiliconWizard on January 01, 2022, 09:37:47 pm
Uh. I've never read Future Shock, but from the description of it ( https://en.wikipedia.org/wiki/Future_Shock ), it seems not that far off. Maybe a few "predictions" were bogus (as most predictions regarding resource depletion are), but I think it still made a number of pretty valid points. Probably too "pessimistic" about dates - things didn't happen quite as fast as it depicts - but we're not that far off from what seems to be described there now. Again, I only read a summary, so maybe there were also many bullshit points in it. But also, maybe the way you read it while being a student was different from how you would perceive it these days?
Title: Re: how to build programming logic?
Post by: brucehoult on January 02, 2022, 02:36:25 am
I don't think the wikipedia article captures the flavour of the book.

Yes, most of the concrete predictions listed in wikipedia have happened. That's not, I think, the point. Everyone from Clarke to Pournelle was predicting those things.

The difference with Toffler, and why I thought he was wrong then and still think he is wrong, is that he regarded these predictable changes as A BAD THING. He regarded it all as being a disaster for human mental health, with people overwhelmed and without hope with no firm foundations. No permanent place. No permanent relationships. etc.

And, on top of that, he was one of those predicting the imminent exhaustion of metals (by 1980 if I recall), oil and gas and coal, constantly increasing pollution, and so forth.

It's all just so wrong, and for very fundamental reasons.

The peak of pollution was just after WW2 and in the 1950s. Since then everything from the rivers and oceans to the air in cities (and globally) has become far *less* polluted. Except in places where the government is in charge of everything, such as the Soviet Union and today's China.

Toffler totally missed that while people might change their physical address and phone number often, other means were developed that enable maintaining permanent relationships -- phone number portability (at least within a country), permanent email addresses (I've been bruce@hoult.org for more than 20 years and always will be in future), and semi-permanent accounts on facebook, twitter, skype, and dozens of others including eevblog -- any one might disappear due to accident or some organisation ceasing to exist, but there is redundancy. In any event they tend to last a lot longer than jobs, phone numbers, and physical addresses.

It must be incredibly difficult for a young person now to imagine how isolating it was to be a teenager (or a wife) on a farm in a rural area in the 1960s. A rural area anywhere even in the UK or USA, but all the more so in somewhere like New Zealand or Australia. There was maybe radio and a newspaper and gradually TV to keep track of what was happening in the outside world, but that was very filtered and superficial. You could get more specialised magazines such as Scientific American or Wireless World, but those were literally three or four months out of date when you got them.

The worst part was that you didn't have a voice. You couldn't *participate*.

Now I can choose to live at a remote beach in the most isolated region of one of the most isolated countries in the world (New Zealand) but I can participate fully (especially in these times without physical conferences) in any world-wide interest I might have. For example I can participate in RISC-V task groups designing new instruction set extensions, and have an actual influence over the results. I can contribute to LLVM or the Linux kernel or anything else that attracts my interest. I can be EMPLOYED by a company anywhere in the world. I can communicate instantly -- by written word, photos, voice, or video -- with anyone who I choose to stay in contact with.

The world -- fifty years after Toffler (and the Club of Rome, and others) made dire predictions of societal and physical collapse 10 or 20 years out -- is not a disaster, it it INFINITELY better in every way than the world of 1970.
Title: Re: how to build programming logic?
Post by: SiliconWizard on January 02, 2022, 02:49:42 am
I get your points, but many of them are definitely debatable.
Title: Re: how to build programming logic?
Post by: MarkMLl on January 02, 2022, 09:38:11 am
The peak of pollution was just after WW2 and in the 1950s. Since then everything from the rivers and oceans to the air in cities (and globally) has become far *less* polluted. Except in places where the government is in charge of everything, such as the Soviet Union and today's China.

And the reason that pollution in the West has reduced is that all of the production has moved to China.

MarkMLl
Title: Re: how to build programming logic?
Post by: brucehoult on January 02, 2022, 10:33:55 am
The peak of pollution was just after WW2 and in the 1950s. Since then everything from the rivers and oceans to the air in cities (and globally) has become far *less* polluted. Except in places where the government is in charge of everything, such as the Soviet Union and today's China.

And the reason that pollution in the West has reduced is that all of the production has moved to China.

That's a very recent change and largely just a neutral shuffling around so some people can claim ridiculously high reduction numbers in their back yeard. Global pollution has been steadily, unexcitingly, reducing for 60+ years.
Title: Re: how to build programming logic?
Post by: Siwastaja on January 02, 2022, 12:43:18 pm
I get your points, but many of them are definitely debatable.

Yeah, and many of the truly large changes are still recent, we can't see their effects yet.

Just 15 years ago people pretty much interacted with each other just like 50 or 100 years ago, or when alone, had moments of "nothing to do".

"Boomers" already sat in front of the TV for maybe 3-4 hours straight. Just like later generations sat in front of PC. Phone calls replaced writing letters, and emails and chat software on PCs replaced phone calls.

But being continuously, like literally 24/7, glued to a mobile personal entertainment device, and being completely emotionally absent even when physically together, is a really new phenomenon invented around 2010.

We don't have any data yet how it affects our future generations. We will know after another decade or two. I don't know, but there are certainly risks involved in such large and sudden behavior change.
Title: Re: how to build programming logic?
Post by: SiliconWizard on January 02, 2022, 05:24:05 pm
We can already see some of the effects IMHO.
Title: Re: how to build programming logic?
Post by: brucehoult on January 02, 2022, 10:40:19 pm
Just 15 years ago people pretty much interacted with each other just like 50 or 100 years ago, or when alone, had moments of "nothing to do".

Smartphones made a change, but many or most people has SMS for instant communication from around 1998. That's what Twitter was build around, at first.

I've been running the family@hoult.org mailing list with about 50 people on it since May 2000. (As a simple .forward file with no spam protection for the first few years but not now so don't even think about it :p )

I've been participating in international BBS's since 1986. I bought my first home computer (a Mac IIcx) in 1989 not because I couldn't afford one before then, but because the capability had improved and MOSTLY because cheap Chinese 2400 bps modems had just become available and a local BBS had started carrying email and usenet via uucp. A permanent link (and telnet and ftp and gopher etc) followed soon after.

I had my first online liaison in 1991. I was in Wellington NZ, she was in NYC. She came to NZ for the month of May 91 and we toured the North Island on my motorcycle and the South Island in my sister's car. I went to NY for a month at Christmas and NY. We're still in touch from time to time. Perhaps weirdly, she later dated RMS and he writes warmly about her on the front page of stallman.org

As Gibson said on NPR in 1993 "The future is already here, it's just unevenly distributed".

The iPhone and Android brought in most of the population of the world -- and made things more convenient for the early adopters -- but some of us have been having (or initiating) many of our most important interactions online for 35 years already.

Quote
"Boomers" already sat in front of the TV for maybe 3-4 hours straight.

My parents did in the 1970s, from the 6 PM news until bed time at 10 or 11. So did my grandparents, in the time I knew them.

This wasn't entirely new -- TV just replaced radio, which had been evening entertainment for captive millions starting about 100 years ago.

I've never been in the habit of just sitting in front of TV watching whatever is served up. As a kid I knew when my show was on, watched it, then disappeared to my room to build something or read a book.

Now, yes, I spend that time and more in front of a computer. But I think it's different. I'm actively doing, creating, something. Or communicating with people, such as those here on eevblog, not just passively being broadcast at.

Quote
But being continuously, like literally 24/7, glued to a mobile personal entertainment device, and being completely emotionally absent even when physically together, is a really new phenomenon invented around 2010.

I don't understand and don't like people continually using their phones when they have a specific meeting with a friend or date. I try very hard not to do that. Even twenty years ago I ignored my mobile phone if it rang while I was with someone -- often much to their consternation ... "You HAVE TO answer a ringing phone". No I don't.

With smartphones sometimes a point comes up that someone wants to check a reference and I think that's fine if it's just occasional.

I'm not concerned about partners on a sofa at home each absorbed in their phones. You can't interact 100% of the time, and people have been snuggling up with their partners with each read a book for centuries.

There definitely are people focussing excessively on their phone when they are with other people. I suspect (and hope) this will self-correct over time.
Title: Re: how to build programming logic?
Post by: snarkysparky on January 03, 2022, 08:49:22 pm

" Global pollution has been steadily, unexcitingly, reducing for 60+ years."


I would like to read more about that.  Is there a source you can supply?
Title: Re: how to build programming logic?
Post by: Nominal Animal on January 03, 2022, 11:22:03 pm
I'm not brucehoult, but I have some links:

However, some types of emissions have not peaked yet.  The main one being carbon dioxide, of course:

If we measure global pollution by the number of deaths it causes in the world, then we're making astonishing progress right now, and have done so for at least the last three decades.
Title: Re: how to build programming logic?
Post by: MarkMLl on January 04, 2022, 08:55:08 am
If we measure global pollution by the number of deaths it causes in the world, then we're making astonishing progress right now, and have done so for at least the last three decades.

/Reported/ number of deaths. I'm very sorry, but I do not believe that large chunks of the World are both able and willing to produce reliable figures.

MarkMLl
Title: Re: how to build programming logic?
Post by: brucehoult on January 04, 2022, 09:34:01 am
If we measure global pollution by the number of deaths it causes in the world, then we're making astonishing progress right now, and have done so for at least the last three decades.

/Reported/ number of deaths. I'm very sorry, but I do not believe that large chunks of the World are both able and willing to produce reliable figures.

A reasonable point, but I don't believe that is getting *worse* over time. Despite the current governments of China and to a lesser degree Russia.

I personally also have huge doubts about our supposed ability to know the average temperature of the surface of the Earth (or even single points) to 0.01 C or even 1 C a century ago. We do know daily maxima and minima to a pretty reliable 1 C/F for a few thousand quite strongly clustered locations a century ago (or maybe even 150 years) but it's not at all the same thing. It's been a different story since satellites went up, but that's only ~1980.

General note: on subjects that (regrettably) have a political component rather than being purely technical I'm willing to state my position, so that the undecided are aware such a position is held by otherwise-rational people, but I'm not willing to defend or debate it. There *is* no incontrovertible truth on such matters, you can never convince someone who strongly holds an opposing position. Only time will tell.
Title: Re: how to build programming logic?
Post by: Siwastaja on January 04, 2022, 10:00:50 am
I've been participating in international BBS's since 1986.

Yeah. I'm significantly younger, which also means I grew up with modern "connected" home computers, and participated in BBS's already as a small kid, tried to run one, too. Then the Internet become available for common households, replacing the BBS scene. Being connected and utilizing technology for entertainment comes completely naturally for me and some, but nearly not all of my age.

Even then, if some of our generation spent like 5 hours a day in front of the computer, this was generally considered a serious mental health risk. Parents were worried, media was worried.

"Information overload" was an actual term.

While spending maybe 2-3 hours per day with tech entertainment/connectivity was considered safe limit 20-30 years ago, now 16 hours is expected as normal.

Watching whole seasons of series on a regular basis, maybe overnight, was considered some sick extremist nerd act (normal people would watch series one episode a week). Now this is what everybody expects normal people to do. The change is huge, it's like two orders of magnitude!

This is a recent and large change, and some people like me, "tech addicts" since small kid, are not keeping up at all, I have become pretty much what was normal 20 years ago, yet now people count me as the strange one again. I don't even have a smartphone. I didn't change my behavior at all. I was too nerdy and tech addicted 20-25 years ago. Now I'm too little of that!

This being said, I agree that nearly not everyone are addicted enough to be glued 24/7 on their interrupt generators, not everybody have a problem. But alarmingly many are. Heck, even if just 1% are, this seems like a huge risk for the society. It likely will result in more neglected kids, and more broken communication than ever. Right now, here an entertainment service company is running radio advertisements where they pretty much describe how a parent addicted in their services neglects their kids by not providing them with food. They make it a "funny" joke. No one bats an eye because people think this is funny, as it is just normal. But maybe I'm just a party pooper and alarmist for no reason, I don't know. I still don't like that joke because I don't like the reality it describes.
Title: Re: how to build programming logic?
Post by: MarkMLl on January 04, 2022, 10:14:23 am
I personally also have huge doubts about our supposed ability to know the average temperature of the surface of the Earth (or even single points) to 0.01 C or even 1 C a century ago. We do know daily maxima and minima to a pretty reliable 1 C/F for a few thousand quite strongly clustered locations a century ago (or maybe even 150 years) but it's not at all the same thing. It's been a different story since satellites went up, but that's only ~1980.

Another reasonable point. But irrespective of potential gaps and discrepancies in the historical or geographical record, my experience tells me that the climate has changed over the last few decades, and at that point I am prepared to accept the figures (which are the mean of many localised studies and are to some extent smoothed over multiple years) that underlie the "hockey stick" model.

MarkMLl
Title: Re: how to build programming logic?
Post by: brucehoult on January 04, 2022, 10:59:38 am
I personally also have huge doubts about our supposed ability to know the average temperature of the surface of the Earth (or even single points) to 0.01 C or even 1 C a century ago. We do know daily maxima and minima to a pretty reliable 1 C/F for a few thousand quite strongly clustered locations a century ago (or maybe even 150 years) but it's not at all the same thing. It's been a different story since satellites went up, but that's only ~1980.

Another reasonable point. But irrespective of potential gaps and discrepancies in the historical or geographical record, my experience tells me that the climate has changed over the last few decades, and at that point I am prepared to accept the figures (which are the mean of many localised studies and are to some extent smoothed over multiple years) that underlie the "hockey stick" model.

MarkMLl

Oh, the hockey stick is just completely debunked. Once it was known what algorithm/code was used by Mann, it was shown that feeding any set of completely random data into his algorithm would produce a hockey stick.

Even just the idea of treating geological data (hugely smoothed and with large error bars) and daily observational data as a single time series is ludicrous.

I'm not quite (months) finished my 6th decade on this planet so don't have a lot of data compared to some, but I can't see any personally observed data that is anywhere near strong enough to reject the null hypothesis that the climate is not changing on a long term permanent basis. There are weather patterns covering several years or a decade, certainly, e.g. our current La Nina. But they reverse.
Title: Re: how to build programming logic?
Post by: Nominal Animal on January 04, 2022, 12:48:45 pm
/Reported/ number of deaths. I'm very sorry, but I do not believe that large chunks of the World are both able and willing to produce reliable figures.
So, you believe that gut feeling is a better indicator than widely accepted approximate figures and statistics?   :-//

Statistics are not perfect, nor usually too accurate.  But they're best tool we have for the job.

Your own experience is just one data point among many.  Valuing it over statistics is a typical human folly.

My own experience contains both statistically useful data points, as well as utterly unlikely coincidences that are rather odd and unbelievable.  I'm not sure which is which, which is why I try hard to point out when I base things on my own experience, my own opinion, corraborated statistics, or a personal idea or gut feeling; so that it can be debated whether the data point has merit or not.

As to the links, they're not from an overly optimistic source.  Quite the contrary, Our World in Data (https://ourworldindata.org/about) tries to highlight the problems.  The fact that they agree that human deaths due to pollution are in steep decline over the last three decades, is a meaningful data point in itself.

I also tried to show that not everything is good news.  Human fertility is also in steep decline in the developed countries, and we don't know exactly why.  There could be genetic damage due to environmental pollution we don't know yet.  So, the links I posted are just some data points, and not the whole truth by a mile.
It's just that personal beliefs and gut feelings and individual experiences have zero useful input on things at the planetary scale; we individual humans are too small and too short-lived for that.
Title: Re: how to build programming logic?
Post by: Siwastaja on January 04, 2022, 01:23:21 pm
I think a simple example proves how flaky "personal experience" is:

We all experience the very same climate. Yet, if you ask about opinions, some will strongly claim that their own experiences show how climate has warmed "significantly" in just a few decades; no more cold and snowy winters like before. At the same time, others who experienced the exact same climate and weather conditions - i.e., someone else who lives close by to have 1:1 the same factual experience, says the opposite, how they personally can testify that climate has definitely not changed.

This is because both have an expected outcome for political/whatever reasons, causing confirmation bias, even if they tried their best to be honest. For example, two years ago we had exceptionally warm and snowless winter. But last winter again was really traditional cold winter with a lot of snow. It's matter of your personal bias which one you remember more strongly.
Title: Re: how to build programming logic?
Post by: MarkMLl on January 04, 2022, 02:32:40 pm
Oh, the hockey stick is just completely debunked. Once it was known what algorithm/code was used by Mann, it was shown that feeding any set of completely random data into his algorithm would produce a hockey stick.

I do not believe that that has been established with any degree of confidence, i.e. that any paper attempting to debunk the "hockey stick curve" has passed peer review and been accepted by a major journal.

Subject to the usual subjectivity about the definition of "major journal" etc.

MarkMLl
Title: Re: how to build programming logic?
Post by: Siwastaja on January 04, 2022, 04:59:28 pm
Oh but you don't need peer reviews and journals for that.

Just publish the data and let people replicate it. I.e., the classic cut the talk, show the proof.

Yes, I have published papers, yes, in journals. I was deeply shocked (but not surprised) to see the quality of the process. Peer reviewers are not necessarily up to task at all, and a lot of BS has passed through, and similarly, significant research can be blocked due to noninterest of journals, which are, after all, businesses that get their revenue by publishing suitable content.

So while I'm critical about brucehoult's claims, the part of not being in journals is uninteresting IMHO. I'd like to see the proof, then it's completely irrelevant what the social status of that proof is because I can make my own conclusions, being scientist enough (like many on this forum, for example).
Title: Re: how to build programming logic?
Post by: nctnico on January 04, 2022, 05:36:58 pm
Quote
Does anybody use flowcharts anymore?

Kind of. I pretty much always do a state transition diagram for a state machine. Flow charts, not so much but if it makes a non-obvious thing simpler then I will. The thing nowadays is UML (or SYSML for embedded) but you really need to speak it to read it, and a flow chart is understandable without prior training.
I'm using flow charts / state diagrams all the time. Helps to break down problems in pieces and write code others can understand.
Title: Re: how to build programming logic?
Post by: SiliconWizard on January 04, 2022, 05:44:42 pm

" Global pollution has been steadily, unexcitingly, reducing for 60+ years."


I would like to read more about that.  Is there a source you can supply?

The problem with that is you can make figures say what you want and its opposite.

Here, the point is too vague to allow eliciting any relevant figure IMHO.
We need to define what pollution means, to begin with. What are the pollutants included? Are we considering absolute levels, or relative to the allowed levels that keep changing over the years?

The decrease is probably true for some pollutants, and absolutely not for others. The impact on health is also hard to determine for some of them. So, as it's hard, we can claim there is none.

Title: Re: how to build programming logic?
Post by: snarkysparky on January 04, 2022, 06:01:09 pm
Pollution level is the relative mass density of non natural materials in the environment.

I am of the opinion that the hockey stick has been verified independent of the original Mann study dozens of times since his publication.  True ??

Title: Re: how to build programming logic?
Post by: Siwastaja on January 04, 2022, 06:19:58 pm
What "nonnatural"? Supernatural? From the fifth dimension?

If you just mean "amount of something exceeding what would be there without human", then how are you going to reliably simulate what the levels would be without human contribution? You know just volcanic activity spews sulfur compounds into the atmosphere.

You make it sound like an easy definition but it really isn't. All we can do is to approximate, simulate, and discuss.

Exact and robust definitions is the foundation for fruitful scientific discussion.
Title: Re: how to build programming logic?
Post by: Nominal Animal on January 04, 2022, 06:31:48 pm
Pollution level is the relative mass density of non natural materials in the environment.
I guess the largest disagreements and differences are in the definition, "non-natural".

Some, like plastics, are easy, since they are so rare in nature we can count all of them as non-natural.

Carbon dioxide is particularly difficult, because even small increase in temperature at the continental shelf seabottom can release significant amounts from methane clathrates; similarly for permafrost in the Arctic, especially Siberia.

Volcanic activity (atmospheric particulates and ash) and even large wildfires throw all sorts of air pollution measurements haywire, because we just cannot differentiate the sources; we can only infer and assume.  It also throws off any sulphur dioxide measurements.

Soil pollution is the one I personally am most interested in, but it seems to be very hard to find any kind of global statistics on that.  Most countries don't gather any.
(It annoys me to no end that general population is unable to understand that powdered depleted uranium is much more deadly than chunks of radioactive uranium.  As a heavy metal, it is at least twice as chemically poisonous than the effects of radiation; that is, the LD50 of depleted uranium in powdered form is the same as for radioactive uranium isotopes, because it is chemically deadlier than say mercury or lead.)

I don't know how much peer review lends credence to gathered statistics, but I suspect not very much.  There is so much politics in gathering statistics, publishing findings, and peer review, that the systematic errors are significant.  It is good that we can discuss which statistics are believable and which not, and why –– although this is the wrong thread for that; I apologise to the OP, for participating in thread-derailing! –– but a plain "I don't think so" without the basis as to why is not useful, because it cannot be considered on its merit: it is relying on authority, which I absolutely hate.  (Argumentum ab auctoritate :rant:)
To repeat, the links I provided are to an organization that would benefit more from fear-mongering and danger-alerting, which is why I consider their report of reducing air pollution and better sanitation credible: I do not see how they'd benefit from reporting that if it was false, only the opposite.
Title: Re: how to build programming logic?
Post by: metebalci on January 04, 2022, 06:37:43 pm
I am computer engineering student(Our curriculum is 80% similar to electronics engineering in our country so you can call me electronics engineering student as well tbh). But this thing is relevant to electronics engineering as well so I am asking it here. I still don't know how to program. I of course can code very tiny tiny programs like prime number etc etc...But I am nowhere near the level of building big programs like using frameworks to make stuffs and so on.

I dont know at which year you are in the university. It can be very similar in the first two years, and it is not necessarily a bad thing. It was ~20y ago, but I studied both of the programs (electronics & computer), so I know similarities and differences pretty well (of course biased, depends on country and university). Also, you say your program is named computer engineering, usually computer engineering is more close to electronics than computer science programs.

If after first two/two-and-a-half years they are still too similar (which is weird, either electronics is too computer-ish, or computer is too electronic-ish), check the curriculum of the computer degree program of a few well known universities. There are very basic, and must have classes that should be common, so if you miss any of these in your university, try to study on your own, so many very good resources on internet now.

Of course these are relative terms, there are exceptions and no rules, but you will probably be nowhere near writing a "big" software until you finish the school and work for a few years. Dont worry if this is the case, it is normal.

I learnt c, c++ and python and bit of javascript. But all of them were useless. I learnt programming languages and not programming.

It is pretty difficult to "know" computer languages to an extent you can say you are comfortable with them to express what you want well. I learned BASIC and Pascal when I was a kid, used them many years for fun. I learned and used c after high school often, but I can never say I know it well. I used c++ somehow at an advanced level for a time period during commercial game development, I remember almost none now. I used python maybe for 15 years, but never made a big software, so I cant say I know it. I loved LISP variants (Clojure), I am nowhere near knowing it. I used Java heavily and commercially, even with that it was hard to say I know it well. The comfort you have with the languages all depend on exercise. As you do with a foreign language or a musical instrument, the more and heavily you use one, you become more and more comfortable using it. When you know a language better, you also get better at expressing yourself with that language. When you know the computer science basics, it is not difficult to express a problem with them if you are comfortable with the language. Neither alone is enough to get better at programming.

It is early for you to think about this but also languages have a certain history and have a different level or sense of expression. C, Java and Python are all very different, LISP is another world. You would not like programming in Java if you write a device driver, you would not like C if you do something else etc. Unfortunately it takes time to have a sense of this, and cannot be learned from the books alone.

I know assebly language coding in 8085 and 8086 microprocessor. I didn't learn 8051 quite well though.

Programming itself is a large topic like computer science and electronics eng. It is easy to say you have to focus on something, but it is hard to do (what to focus on?). But at the end you will not be good at many things, so accept it as early as possible. Once, I knew PC architecture pretty well, then I knew Windows pretty well, then I knew mobile world well, then backend/server etc., but this covers like 25-30 years. I only coded a very simple device driver once for fun, so it is normal to not know things. After some time, the important thing is not to know how to do it, but to know how to learn how to do it.

Because you mentioned the CPUs, one of the classes you have to learn well is computer architecture. This is normally not taught in electronics. The other classes, most of them if not all, normally not taught in electronics: algorithm analysis, operating systems, abstract math/formal languages/automata theory, computer networks. Depending on what you do, you might not use what you learned in some of these classes at all, but they will give you something valuable which can be applied anytime to any problem.

There are also artificial intelligence and machine learning classes, but they might be advanced and given only at post-graduate level.

I think this question is relevant to electronics engineering students in my country(Nepal) as most electronics engineering students pursue career in coding like web development. Any way, coding is essential part of electronics engineering, we all know about that.

Probably in many countries if not all countries, there are more computer/IT/software related jobs than electronics, so I think it is pretty normal particularly if the country does not have a strong electronics industry (nothing against Nepal, only a few countries have strong electronics industry).

I am currently learning python. I learnt syntax of python. And I am currently solving codewars problems. I read other person's solutions as well and try to understand at least 5 different solutions to a problem. My logic has improved a bit in programming but I consciously want to know how to improve my logic in programming? What else can I do to improve my logic in programming? Any guidance will be extremely valuable.

Other than learning the basics from the books, lectures etc. I think two best things to do; 1) read others code (so many very good open source projects), 2) write code (find a project, fix something in another project or do internship/work part-time in a company). Python is a good choice by the way. If you have hard time to find a project, just copy the idea and re-implement a simple version of an existing software (e.g. write a web server).
Title: Re: how to build programming logic?
Post by: MarkMLl on January 04, 2022, 06:41:46 pm
(It annoys me to no end that general population is unable to understand that powdered depleted uranium is much more deadly than chunks of radioactive uranium.  As a heavy metal, it is at least twice as chemically poisonous than the effects of radiation; that is, the LD50 of depleted uranium in powdered form is the same as for radioactive uranium isotopes, because it is chemically deadlier than say mercury or lead.)

Obligatory "Nearing Zero": https://sites.google.com/site/htzhaocn2/nz017.jpg

MarkMLl
Title: Re: how to build programming logic?
Post by: brucehoult on January 04, 2022, 10:04:02 pm
Oh, the hockey stick is just completely debunked. Once it was known what algorithm/code was used by Mann, it was shown that feeding any set of completely random data into his algorithm would produce a hockey stick.

I do not believe that that has been established with any degree of confidence, i.e. that any paper attempting to debunk the "hockey stick curve" has passed peer review and been accepted by a major journal.

Better than that, Mann's source code is available (has been for quite some years) and you can run it yourself.
Title: Re: how to build programming logic?
Post by: rstofer on January 05, 2022, 06:20:28 pm
There are also artificial intelligence and machine learning classes, but they might be advanced and given only at post-graduate level.

Wouldn't Linear Algebra be part of any undergrad STEM program?  I remember spending some amount of time on matrix inversion, multiplication and such clear back prior to '73.  We only did up to 4x4 but we did it by hand, very few students had access to a computer (I was one of them).  I'm far from competent in ML but it seems to me that all of this AI stuff is based on Linear Algebra (and Partial Differential Equations).
Title: Re: how to build programming logic?
Post by: metebalci on January 05, 2022, 06:49:04 pm
There are also artificial intelligence and machine learning classes, but they might be advanced and given only at post-graduate level.

Wouldn't Linear Algebra be part of any undergrad STEM program?  I remember spending some amount of time on matrix inversion, multiplication and such clear back prior to '73.  We only did up to 4x4 but we did it by hand, very few students had access to a computer (I was one of them).  I'm far from competent in ML but it seems to me that all of this AI stuff is based on Linear Algebra (and Partial Differential Equations).

Linear algebra is a very basic one and taught in many disciplines maybe even in non-STEM areas. I wrote only the ones that is quite specific to computer sci./eng. The specificity also blurs as you go higher in education. AI and ML might be taken by other disciplines, and a computer scientist/engineer might take a very different courses too. I meant only the very directly related and undergrad ones and probably I miss a few.