User avatar
DavidS
Posts: 3794
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Solution to X-Toolkit and portability.

Sun Nov 13, 2016 6:21 pm

One of the issues I went to sleep thinking about was that of an X-Toolkit as well as that of portability. I had been looking at the many many options, and weighing the pros and cons of each of the options.

A solution that improves portability by many times, provides a cross-platform means of implementing a GUI, and is capable of being very efficient came to me as I slept in the night.

The solution is MS-BASIC, more accurately QuickBASIC/FreeBASIC/QB64. This has the advantage that if written in the FB-Lite dialect it gives code that is easy to port to DOS and old Macintosh System Software as it is easy to modify to compile with QuickBASIC, and there is a DOS port of FreeBASIC already.

There are similar compilers on many platforms.

Also FreeBASIC itself is available for Win32, MS/DR/FREE/Rx-DOS, Linux x86, Linux ARM, BSD, Atari Falcon/TT, Amiga, and a few other platforms, being designed to be easy to port.

Thus the issue of portability is solved in a single stroke with the use of the FB-Lite or QB dialect of FreeBASIC. At the moment it leaves out only RISC OS as modern Operating Systems go.

As for the GUI stuff, well the use of the FreeBASIC Graphics Library means that there is little concern about platform specifics. And it is a lot easier to use than X.

:).
RPi = Way for me to have fun and save power.
100% Off Grid.
Household TTL Electricity Usage = 1.4KW/h per day.
500W Solar System, produces 2.8KW/h per day average.

User avatar
PeterO
Posts: 4464
Joined: Sun Jul 22, 2012 4:14 pm

Re: Solution to X-Toolkit and portability.

Sun Nov 13, 2016 6:27 pm

No one cares about your dreams !
PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

Heater
Posts: 11399
Joined: Tue Jul 17, 2012 3:02 pm

Re: Solution to X-Toolkit and portability.

Sun Nov 13, 2016 8:07 pm

Yep, great idea.

Except nobody wants to write in BASIC anymore.

In the modern world the issue of portability is solved by:

a) Do the hard part on servers in the "cloud".

b) Do the GUI part in the web browser.

User avatar
[email protected]
Posts: 2014
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
Contact: Website

Re: Solution to X-Toolkit and portability.

Sun Nov 13, 2016 9:52 pm

Heater wrote:Yep, great idea.

Except nobody wants to write in BASIC anymore.
I do!

But I don't want to write a GUI/x-Toolkit in one. I did that in C.

-Gordon
--
Gordons projects: https://projects.drogon.net/

User avatar
DavidS
Posts: 3794
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Solution to X-Toolkit and portability.

Sun Nov 13, 2016 10:03 pm

Heater wrote:Yep, great idea.

Except nobody wants to write in BASIC anymore.

In the modern world the issue of portability is solved by:

a) Do the hard part on servers in the "cloud".

b) Do the GUI part in the web browser.
Yea write your local use only non-networked applications that way, it is up to you.
RPi = Way for me to have fun and save power.
100% Off Grid.
Household TTL Electricity Usage = 1.4KW/h per day.
500W Solar System, produces 2.8KW/h per day average.

User avatar
DavidS
Posts: 3794
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Solution to X-Toolkit and portability.

Sun Nov 13, 2016 10:04 pm

PeterO wrote:No one cares about your dreams !
PeterO
Think you got the wrong thread, sorry.
RPi = Way for me to have fun and save power.
100% Off Grid.
Household TTL Electricity Usage = 1.4KW/h per day.
500W Solar System, produces 2.8KW/h per day average.

Heater
Posts: 11399
Joined: Tue Jul 17, 2012 3:02 pm

Re: Solution to X-Toolkit and portability.

Mon Nov 14, 2016 12:17 am

DavidS,
...write your local use only non-networked applications that way, it is up to you.
Sure, why not? Nobody said the "cloud" part had to be remote over the net. The server could as well be on your local machine.

Or now you can combine the server and the browser into one, with Electron for example. http://electron.atom.io/

More philosophically, one could say that as soon as one is talking about portability one is talking about moving code from machine to machine. That is to say networking.

User avatar
DavidS
Posts: 3794
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Solution to X-Toolkit and portability.

Mon Nov 14, 2016 3:01 am

Heater wrote:More philosophically, one could say that as soon as one is talking about portability one is talking about moving code from machine to machine. That is to say networking.
:)

And from another philosophy one could say that if talking about porting you are talking about writing as memory and resource efficient code as possible, and avoiding the overhead of interpreters. Thus because real portability means lowest common denominator. :)
RPi = Way for me to have fun and save power.
100% Off Grid.
Household TTL Electricity Usage = 1.4KW/h per day.
500W Solar System, produces 2.8KW/h per day average.

User avatar
DavidS
Posts: 3794
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Solution to X-Toolkit and portability.

Mon Nov 14, 2016 3:03 am

[email protected] wrote:
Heater wrote:Yep, great idea.

Except nobody wants to write in BASIC anymore.
I do!

But I don't want to write a GUI/x-Toolkit in one. I did that in C.

-Gordon
For what do you use BASIC?

On RISC OS we often use BASIC for writing fully integrated desktop apps, that take full advantage of the Windowing System and just about any other feature of the OS. That is all in interpreted BASIC, and done because it is often easier, faster, and more effecient in mem and CPU for the result.

If there were ARM BASIC for ARM Linux with a complete simulation of at least the WIMP system calls I would use it all day long. ARM BASIC is very fast, nearing the speed of non-optimized compiled code in many cases (not all) do to the way it is written (thanks to SW).

The ARM BASIC interpreter is small enough it runs completely in Instruction Cache, and the programs usually fit into a small amount of Data Cache, making it so that cahce misses are much rarer with BASIC programs than with most traditional compiled programs, thus improving the speed by a large factor. Now tight loops and such will be a lot faster in compiled programs, as will be things that make specific use of VFP/NEON. Though for those things we have the builtin ARM assembler in ARM BASIC, so we can make our routines as fast as even optimized code in compiled languages.

Sorry for going on. ARM BASIC is my prefered programming language, and as such I tend to get on a bit much when talking about it.
RPi = Way for me to have fun and save power.
100% Off Grid.
Household TTL Electricity Usage = 1.4KW/h per day.
500W Solar System, produces 2.8KW/h per day average.

User avatar
[email protected]
Posts: 2014
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
Contact: Website

Re: Solution to X-Toolkit and portability.

Mon Nov 14, 2016 8:18 am

DavidS wrote:
[email protected] wrote:
Heater wrote:Yep, great idea.

Except nobody wants to write in BASIC anymore.
I do!

But I don't want to write a GUI/x-Toolkit in one. I did that in C.

-Gordon
For what do you use BASIC?
For fun and profit.

I've done a few commercial data analysis jobs using it recently. Some things that would have been problematic in a spreadsheet (apparently - I'm not a spreadsheet guru, but when faced with several files of CSV numbers I found it easy to write a program to do what was needed with them - and I get paid for it - always a bonus :)

There are also a few 100 avid users of my RTB too - mostly older folks who just want to have a bit of fun with something like the 8-bit micros they grew up with. The convenience of a modern OS with the fun of an old style BASIC interpreter.

-Gordon
--
Gordons projects: https://projects.drogon.net/

ejolson
Posts: 2603
Joined: Tue Mar 18, 2014 11:47 am

Re: Solution to X-Toolkit and portability.

Mon Nov 14, 2016 10:17 pm

Heater wrote:In the modern world the issue of portability is solved by:

a) Do the hard part on servers in the "cloud".

b) Do the GUI part in the web browser.
Clouds solve copy protection and licensing issues without needing to run any kind of DRM or trusted compute platform. Since all clouds are different as are most browsers, browser apps and clouds don't solve the portability issue. It is possible the issue is made even worse.

The label on the Kool-Aid says sugar free. That means you have to add you're own sugar to make it drinkable. However, if you need to audit the source code or the ingredients, it might be better to not drink the Kool-Aid.

User avatar
DavidS
Posts: 3794
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Solution to X-Toolkit and portability.

Tue Nov 15, 2016 3:08 am

There is a quote I remember and like, can not remember the original source anymore.

The quote:
"There are three ways of coding, there is the modern Accepted Standard, Extreme Obfoscution, and Good Coding, I prefer the last."

I do remember that the originator was pointing out that the modern standard of doing things is not of any use, and worse than the second option.

Same source (if memory serves) stated that using resources for the purpose of quick coding is poor practice, and that using an HLL for what can more easily be done in Assembly is a waste of time.

Needless to say the reason I remember these as they agree with my point of view 100%.

On The New CPU's
It seems that features are being changed to benifit only the writers of compilers, and then only the ones that use obscure means of optimization. It seems as if the designers of the latest generations of CPU's have forgotten that we will have to trace the code in machine language even if it is written in an HLL.

Some of the way that things have changed with the ARMv8 are nearly sickening. Though at least with the ARMv8 old code does benifit from the changes, as long as it actualy still runs on the ARMv8.

I find myself using an ARMv6 based RPi B to write and assemble code to target the ARMv8 based RPi 3B. This does not seem very good, though it is what is needed to reduce the chances of errors, primarily because of the number of tools that will not run on the ARMv8, though will produce good usable code for the ARMv8 Aarch32.

I will be getting into this a bit more in my blog. Just today I was attempting to double check instructions that I am going to be posting on my site, just to find that the needed tools crash on the ARMv8 even though those particular tools do not use the SWP opcode.
RPi = Way for me to have fun and save power.
100% Off Grid.
Household TTL Electricity Usage = 1.4KW/h per day.
500W Solar System, produces 2.8KW/h per day average.

Heater
Posts: 11399
Joined: Tue Jul 17, 2012 3:02 pm

Re: Solution to X-Toolkit and portability.

Tue Nov 15, 2016 6:20 am

ejolson,
Clouds solve copy protection and licensing issues without needing to run any kind of DRM or trusted compute platform.
Yep. Not something I'm into myself.
Since all clouds are different as are most browsers, browser apps and clouds don't solve the portability issue. It is possible the issue is made even worse
Good point. Yes and no...

Certainly cloud platforms vary and offer different features, API, etc.

On the one hand this is not a problem. There is no need to be porting the cloud services from platform to platform. Whilst at the same time your users can be accessing your services from Windows, Mac, Linux, Android, iOS etc. Thus your portability problem has vanished.

On the other hand, you may want to ensure your cloud services can be moved from cloud provider to cloud provider. Perhaps for cost reasons or whatever. This is something I'm always pushing for in our company just because I feel it's better not have all ones eggs in one basket. Better to not be locked in. As a result we have cloud software that is usable on Google, AWS, Azure, Digital Ocean...

Heck, a lot of it can be run locally on your Mac, Windows or Linux machine, even on a Raspberry Pi.

Historically browsers have varied a lot and been a pain to support. Now a days this problem has all but disappeared. The stuff we produce works fine on IE 11, Edge, Safari, Firefox, Chrome, probably Opera though I have not tried it yet. Users can be on PC, Mac, phones, tablets. All this with hardly any tweaks for different browsers.

How much more portable can we get?
The label on the Kool-Aid says sugar free. That means you have to add you're own sugar to make it drinkable. However, if you need to audit the source code or the ingredients, it might be better to not drink the Kool-Aid.
I did not get that part at all.

Heater
Posts: 11399
Joined: Tue Jul 17, 2012 3:02 pm

Re: Solution to X-Toolkit and portability.

Tue Nov 15, 2016 7:05 am

DavidS,

I do wish you could remember the sources of your quotes and/or link to them. Google does not find anything remotely similar to that one. So it's all rather meaningless.

Anyway, one that I like comes from Alan Perlis:

"There are two ways to write error-free programs; only the third one works."

Certainly to suggest that extreme obfuscation is preferable to almost any modern coding practice is said with tongue in cheek.

By the way, what is the "modern Accepted Standard"?

Some would say that it is object orient programming. What with the huge amounts of Java, C#, C++ going on in the world. I have always thought that this push to object orient everything was nuts, in certainly does obfuscate programs. It leads to all those hefty books on design patterns and methodologies. All of which seem to be about keeping the object oriented mess under control.

So, after 20 years of thinking I perhaps did not understand the object oriented idea somehow, I was pleased to find I am not alone. Slowly I find more people daring to suggest that all this OOP is a mess that does not actually make solving your problems easier. Even the creator of C++, Bjarne Stroustrup, has said that OOP is vastly over used recently.

So much for modern accepted standards.

It's absurd to say "using an HLL for what can more easily be done in Assembly is a waste of time". Firstly because there is nothing that is more easily done in assembler (barring some processor specific things). Secondly because if you want your program to run on 10 different architectures you are going to have to write it 10 times in assembler vs once in an HLL.

User avatar
DavidS
Posts: 3794
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Solution to X-Toolkit and portability.

Tue Nov 15, 2016 10:10 pm

@Heater:
On the source of the quote, I was curious as well after posting it, so I looked through my notes (on paper).

It turns out that it was my 7th grade CS-162 Professor Dr. Buck PhD. Sorry never knew his first name, though he was in his late 60's then so may no longer be around. Doubt it ever made it to the internet, could be wrong.

He was a stickler about making sure to include his degree when writing his name. Never understood that, I am apposed to waving my degrees (tends to skew things in a biased direction), though he loved showing his.

I have attempted to look him up, though there are to many people that match Dr. Buck PhD when searching.

On Modern Standards:
Now that I know who it came from I can say what he meant by modern standards.

He would have been talking about the use of long overly verbose variable names, and the abuse of dynamic memory allocation (as in freeing some memory just to very soon there after allocate a similar size block for another use).

He believed that the long overly verbose variable names made code a little less readable, I agree with him though I am biased as he was my professor.

He also felt it more efficient to reuse a block of memory than to repeatedly allocate and deallocate small blocks. This makes very good sense, as it is not being wasteful, and is reducing the chances of memory leaks, as well as reducing the number of system calls being made.

So now you know what was meant by modern standards. And it is from a person I agree with.
RPi = Way for me to have fun and save power.
100% Off Grid.
Household TTL Electricity Usage = 1.4KW/h per day.
500W Solar System, produces 2.8KW/h per day average.

User avatar
PeterO
Posts: 4464
Joined: Sun Jul 22, 2012 4:14 pm

Re: Solution to X-Toolkit and portability.

Tue Nov 15, 2016 10:32 pm

DavidS wrote: This makes very good sense, as it is not being wasteful, and is reducing the chances of memory leaks, as well as reducing the number of system calls being made.
It might look like a cogent argument, but in reality it's a non-sequitur.
I would much prefer the overhead of a few malloc/free calls over having to manually keep track of what exactly every allocated block is being reused for at each stage of my code.
PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

Heater
Posts: 11399
Joined: Tue Jul 17, 2012 3:02 pm

Re: Solution to X-Toolkit and portability.

Tue Nov 15, 2016 11:01 pm

I think David has a point here.

Let's say you have a program that collects lots of items and has to add them to some kind of list.

You have some options here:

1) Stick them in an array of contiguous, pre-allocated memory.

2) Malloc or new some new memory for each one as they come.

Well, guess what? If you need to traverse all those elements having them in an array is 100's of times more efficient than having them scattered all over RAM with malloc/new.

Why? Because modern processors are very fast but memory access is slow. But processors have fast local caches. So, if you can keep the data you are working with in cache as much as possible you are flying.

On the other hand, a lot of programs are not dealing with such simple and ordered data. There is no way to keep things in your cache. At which point you may as well give up and use malloc/new. Let the system take care of the details of memory management.

User avatar
DavidS
Posts: 3794
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Solution to X-Toolkit and portability.

Wed Nov 16, 2016 2:28 am

Or if you are doing many things that all take a temperary buffer of some kind (such as common with GUI programming), and each only needs the buffer for a moment, then reusing the same buffer for the next item makes things faster as it is already in cache.

This holds from the late 1980's when caches exceded 256 bytes, and often you will be using data structures that are less than 128 bytes and are only needed for a moment, and replaced as quickly with another buffer.

The overhead of allocating memory and releasing it is also more with modern systems, as it has to map pages into the page table each time you allocate some memory. This is very inefecient. Yes they are using algorithms that improve the situation, though there is still more overhead than with identity mapped systems.

Even if you are allocating memory and freeing it regularly you still have to keep track of what block is used for what, so that you can deallocate it as needed, and prevent memory leaks. And that is the trouble, you must ALWAYS keep track of what memory you are using for what.
RPi = Way for me to have fun and save power.
100% Off Grid.
Household TTL Electricity Usage = 1.4KW/h per day.
500W Solar System, produces 2.8KW/h per day average.

Heater
Posts: 11399
Joined: Tue Jul 17, 2012 3:02 pm

Re: Solution to X-Toolkit and portability.

Wed Nov 16, 2016 6:33 pm

Oddly, modern machines with their terribly inefficient memory mapping and software with dynamic memory allocation are 100's and 1000's of times faster than those 1980's systems that did not do that. Whilst also being thousands of times smaller and more power efficient.

You can easily be wasting more time and energy trying to optimize things the old fashioned way than you ever gain in run time.

We have wasted more joules and created more CO2 discussing this here than any of our code optimization will ever save ! :)

User avatar
DavidS
Posts: 3794
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Solution to X-Toolkit and portability.

Wed Nov 16, 2016 9:00 pm

Heater wrote:Oddly, modern machines with their terribly inefficient memory mapping and software with dynamic memory allocation are 100's and 1000's of times faster than those 1980's systems that did not do that. Whilst also being thousands of times smaller and more power efficient.
+1. Though NOT when you count it in the number of instruction cycles.
You can easily be wasting more time and energy trying to optimize things the old fashioned way than you ever gain in run time.
Often times that is not the point. Often times the point is just getting it to run a little better, or faster, while leaving a little more time for other stuff, and NOT needing newer HW.
We have wasted more joules and created more CO2 discussing this here than any of our code optimization will ever save ! :)
That is NOT the point of optimization, WAY not the point of optimization (at least not for us old school coders).
RPi = Way for me to have fun and save power.
100% Off Grid.
Household TTL Electricity Usage = 1.4KW/h per day.
500W Solar System, produces 2.8KW/h per day average.

User avatar
DavidS
Posts: 3794
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Solution to X-Toolkit and portability.

Wed Nov 16, 2016 9:09 pm

Where optimization saves in Carbon footprint is in not having to upgrade HW so much, and as such reducing the number of newer units that need to be produced.

I am aware of the irony of that, as I have the newest model of RPi. I do not need it, in fact as a personal experiment I have been primarily using an original 2012 RPi Model B clocked at:

Code: Select all

force_turbo=1
arm_freq=400
core_freq=250
gpu_freq=250
sdram_freq=300
over_voltage=0
temp_limit=80
boot_delay=1
Just to see if I realy need the way way more powerful RPi 3B for most of my day to day stuff. There are still compile jobs that I would not attempt on the old RPi, as they take enough time on the 3B @ 1350MHz.

There are definitely some things where the extra power of the RPi 2B is worthwhile, though only a few things. Most things it is just optimization, nothing more.

Though that is not the main point of optimization
The main point of optimization is being able to do more with the HW we have, if we do not do this then we are wasting time, money, and resources by purchasing faster systems.
RPi = Way for me to have fun and save power.
100% Off Grid.
Household TTL Electricity Usage = 1.4KW/h per day.
500W Solar System, produces 2.8KW/h per day average.

Heater
Posts: 11399
Joined: Tue Jul 17, 2012 3:02 pm

Re: Solution to X-Toolkit and portability.

Wed Nov 16, 2016 10:08 pm

I'm not sure I made my point very well.

The question is what are we trying to optimize?

Clearly one view of this is that I have a processor and I want to get it to perform some algorithm as quickly and efficiently as possible. Minimizing it's use of time and energy. To that end I might spend hours honing the code to some optimal perfection.

On the other hand we could make the case that the system we are trying to optimize, as a whole, is made of many more parts than just that particular computer. We have:

1) The computer on which the code runs.

2) The programmer who is going to create that code.

3) The organization that employs the programmer to create that code.

4) The users and the users computers that will run that code.

5) The system that the code ultimately controls. A machine, a factory, an airline, whatever.

Looking at this whole system we might conclude that messing around saving cycles here, bits and bytes there, is a vanishingly small detail that does not have a measurable difference on the overall result. Not worth the bother.

User avatar
DavidS
Posts: 3794
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Solution to X-Toolkit and portability.

Thu Nov 17, 2016 12:51 am

@Heater:
No you had made your point plenty well the first time.

Though it seems I did not make my responce very clear.

I understand where you are coming from.

Though the view that I am coming from is getting the SAME OLD HARDWARE to do more and more so that a good number of people do NOT have to upgrade there hardware nearly as often, and thus reduce the waste of old systems being recycled, and lower the carbon footprint of producing as many new systems.

If this pattern were followed we would be running the RPi 2B as the newest RPi, as there realy is not a need for the 3B yet, if only optimization of the software were a priority.

Though there are those that do optimize software to run better on the same old HW. This is the reason we have NetSurf (which is slowly becoming more complete), why RISC OS is still around, That is why Unix became popular (though is now lost to that), etc, etc.

Unfortunately many share your view, and this pushes us further into the oven of high waste. I may keep ahead of what I need, though many would not keep ahead if they did not NEED it. If software were continously being optimized for better and better performance on equal HW the need to upgrade would be much more of a rarity, maybe every 4 to 6 years if you are doing things that realy push the limit of the HW. This would save on the energy in manufacturing, and the companies that provide the HW would have a buisness model that fits that need.

Though do as you do, and I will do as I do.
RPi = Way for me to have fun and save power.
100% Off Grid.
Household TTL Electricity Usage = 1.4KW/h per day.
500W Solar System, produces 2.8KW/h per day average.

ejolson
Posts: 2603
Joined: Tue Mar 18, 2014 11:47 am

Re: Solution to X-Toolkit and portability.

Thu Nov 17, 2016 4:30 am

DavidS wrote:The main point of optimization is being able to do more with the HW we have, if we do not do this then we are wasting time, money, and resources by purchasing faster systems.
As computers get faster, the problems they are used to solve get bigger (otherwise, what would be the point of using faster computers). As the problems get bigger, using efficient code and algorithms becomes increasingly important. The need for efficiency is seen in codes used to process big data, weather forecasting, financial information and so forth. At the same time, there is also an industry of using fast computers to solve small problems. Therefore, different views on the need for efficient code are not surprising.

Heater
Posts: 11399
Joined: Tue Jul 17, 2012 3:02 pm

Re: Solution to X-Toolkit and portability.

Thu Nov 17, 2016 1:04 pm

I'm all in favor of being frugal. I was never in the habit of replacing systems every year just to keep up with the latest and greatest go faster gizmo. Until recently my main PC was seven or so years old.

However, given the rate of progress over recent decades it is quite likely that keeping old inefficient machines running is pointless. Ending up being more expensive and more power draining than replacing them with something new that saves space and energy whilst out performing the old gear by miles.

Which is why my main machine now is an MS Surface Pro 4. Dozens of times smaller, more efficient and convenient than my big old PC and its honking great CRT monitor. Whilst at the same time being far faster and more capacious.

Any effort to optimize code to run on my old hardware would hardly be noticeable compared the performance gains and power savings obtained by switching to my new machine.

On the other hand, I'm all for expending great effort in optimizing things where it has a big effect. For example kernel code, perfecting compiler optimizers or honing run times for Java, JS, Python etc. These things get a lot of use, all the time, by millions of people so it makes sense to get them performing well.

That does not include wasting ones life writing applications in assembler. That is an anti-optimization. It ensures your code cannot take advantage of any new efficient architecture that comes along in the future.

Return to “Other programming languages”