Products > Programming

Too many programming languages?

<< < (99/101) > >>


--- Quote from: Nominal Animal on December 07, 2019, 11:32:54 pm ---
--- Quote from: brucehoult on December 07, 2019, 10:47:47 pm ---
--- Quote from: tggzzz on December 07, 2019, 08:59:55 pm ---I remember a job interview in 1978 where I was asked about which microprocessor I thought was best. The interviewer liked my response that they were all pretty similar, and that a more important point was the development environment and tools.

--- End quote ---
That's true now, but in 1978?

--- End quote ---
Perhaps the interviewer didn't care about technical accuracy, but the attitude/approach to tools?

I mean, you probably have asked an interviewee which programming language they'd use to solve problem X, then which language they like best, and drawn conclusions about whether they answer with the same programming language or environment for both, instead of which particular languages they mention?  ;)

--- End quote ---

Basically yes.

When. as an interviewer, I've asked such open-ended questions, I've been looking to see to what extent the interviewee can justify their answers. That can reveal a lot about their thought processes, depth/breadth of understanding, and flexibility.


--- Quote from: tggzzz on December 08, 2019, 08:47:22 am ---
In 1978 the only microprocessors that were at all reasonable targets for running languages such as Pascal or C and actually getting most of the available performance capability (and with a reasonable code size) were the 8086 and 6809, both introduced in that year. Or the TMS9900 and LSI-11, but they were quite uncommon.

In early 1978 the 8086 didn't exist. We are thinking about processors such as 8080, 8085, Z80, 1802, 6800, 6502, SCMP, F100.

In 1978 the only Pascal implementation was UCSD p-code. C was not generally known, and the tools would have been primitive. Not interesting to an electronic engineer.

The realistic choice for an HLL was intel's PL/M running in their "blue boxes".

--- End quote ---

All of what you wrote conforms to my memory as well. I believe there may have been mainframe implementations of Pascal extant in that year, it was rapidly gaining popularity with academics as the language you should be teaching beginners.  For micros the choice was assembler or PL/M. Motorola had MPL their PL/M equivalent    for the 6800 family. I ended up using both PLM and MPL on concurrent projects right after graduation.

MPL manual


--- Quote from: Nominal Animal on December 07, 2019, 06:55:25 pm ---human cognitive aspects of programming

--- End quote ---

Well, a lot of scientists in my team, continuously say that "if aircraft could copy the way geese fly, they would save fuel!". But our best AI has never tried to solve this because fuel cost is not our problem.

Google scientists say they've achieved 'quantum supremacy'(1), which means that a programmable quantum device can solve a problem that classical computers practically cannot.

One month ago, their Quantum computer "Sycamore" solved a problem in 200 seconds, while the IBM massive supercomputer "Summit" would have taken 10K years; but IBM guys replied that a "patch" would have accelerated time to solution because "even aggressive centipedes will co-operate if they have to", which better explains what the IBM-patch does on the Supercomputer's nodes to solve the problem in just 3 days rather than in thousands years.

That's a milestone, because until recently, every computer on the planet, from a 1960s mainframe to iPhone, has operated on the same rules. These were rules that Charles Babbage understood in the 1830s and that Alan Turing codified in the 1930s.

Human beings need a solid purpose to do things. Their nature is being lazy, and I am afraid this also applies to the human cognitive aspects of programming  :-//

(1) This phrase was coined by the physicist John Preskill in 2012.

Nominal Animal:

--- Quote from: legacy on December 08, 2019, 01:55:22 pm ---Human beings need a solid purpose to do things.
--- End quote ---
Well, no, just instant gratification.

Consider Foldit. The retroviral protease of M-PMV (monkey HIV/AIDS-like virus) has a crystal structure that was unsolved for 15 years.  Foldit gamified it in 2011, and the players found the enzyme structure in ten days.

True engineers, scientists, and tradesmen who look at things in the longer term, are the oddballs.


--- Quote from: Nominal Animal on December 08, 2019, 04:53:46 pm ---
--- Quote from: legacy on December 08, 2019, 01:55:22 pm ---Human beings need a solid purpose to do things.
--- End quote ---
Well, no, just instant gratification.

--- End quote ---

If you define "instant gratification" by getting an instant result, I agree.

But I think both are more closely related than you seem to think. Having a solid purpose and acting upon it gives us a form of instant gratification, even if we can't see the result. It's all related to how our brain reward system works.

So the relatively small fraction of people being able to act on long term rather than short term is not quite, IMO, due to them not needing "instant gratification" per se, but it's likely due to how their reward system specifically works (it's probably more "efficient"!)

--- Quote from: legacy on December 08, 2019, 01:55:22 pm ---Human beings need a solid purpose to do things.

--- End quote ---

You make it sound as though it was a defect. Actually, all living beings need a purpose for doing anything at all. It's called motivation, and it goes from our very basic needs up to more complex/abstract ones. Doing things without purpose is the oddball. Life does not like wasting energy for no reason. Call that lazyness if you will. In that definition, life is essentially lazy.

The whole point, I think, is not the problem of needing a solid purpose or not for doing things, it's about our capacity of anticipating.


[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Go to full version