AI and decompilation?

Oh. reverse for me. couldn't write an X window program to save my life. Quite happy to design stuff in html and javascript tho

Same, apart from the Javascript and X-Windows: I don't use either.

However, implementing GUI windows in Java with AWT and Swing is easy enough, particularly if you use the 3rd party se.datadosen.riverlayout package to control object placement on windows and panels.

PHP is quite easy to write too, though it can be a bit harder to debug than Java. The O'Reilly PHP book is pretty good.

Curses works well if you just want to format a console screen and, in any case, its easy enough to re-implement if you you need its capabilities in a language that can't call functions from the C standard library.

lines

I'm naive; what's the problem with:

bar: .cfi_startproc ... do something

;;; call foo ;;; ret ; just fallthru to execute foo and exit.

foo: .. do more .. ret

Nothing as long as you only have one bar for your foo, often foo was common finishing for several bars.

easy ?

How someone can object to the ease of overloading is just beyond me.

Den 2021-01-06 kl. 19:37, skrev The Natural Philosopher:

an language that needs

• 'loose comparison' ==

• 'strict comparison' ===

with accompanying truth tables that are not-so-obvious is just a bad joke.

true == 0 -> false true === 0 -> false

true == 1 -> true true === 1 -> false

WTF?

Den 2021-01-06 kl. 10:32, skrev The Natural Philosopher:

Most coder are not smart. They do cut & paste with all error that comes from it. Having a language that compiles everything but fails at run-time is a sure way to the debugger and maintenance hell and high costs.

Some say a good coder get by in any language - I say bullshit. The language is the coders tool -nothing else.

A truck is the truck drivers tool. And If I want to move 50 tons of sand efficiently I use a truck - not a tuk-tuk. Even though I recognize that a tuk.tuk can be used. But it is the wrong tool for the job.

And the job _most_ coders have is maintenance. And a stupid language is the wrong tool for that.

Instead - a strongly typed langue is the right tool, since it gives _compile-time-errors_ that are cheap to fix, instead of run-time errors that are more expensive to fix. And deployed at customer - and crash ? downtime is very expensive - at least if the code does something significant for the customer. One of our customer says ?150_000/hr for downtime.

It's very simple. It makes things that behave very differently look exactly the same.

which is a recipe for disaster

That can be a good thing, used well it simply puts irrelevant detail out of sight, used badly it creates as much confusion as #define ONE 2.

If you use overloading that way, you're an idiot or a coder trying to lock in a job for life...

To see overloading being used sensibly, look at the TreeMap constructors, the String constructors or String.indexOf() methods in the Java Standard Edition API Specification There are also some good examples of overloading in "A very Informal Introduction to Algol 68", which, by the way, is not only an excellent way to learn A68, but is the only serious programming language manual that has made me laugh out loud in places.

That sounds like a description of one of those bogus programming languages that pops up in humour columns from time to time. One of them proposed an operator meaning "is more equal than" (shades of Animal Farm).

Make that value comparison ...

... and value and type comparison

Yep 0 is not a true value

Yep 0 is not a boolean

Yep 1 is a true value

Yep 1 is not a boolean

Seems fine to me, you just have to understand what it means like any other language construct.

Nope just someone who doesn't understand the language and wants to complain.

It was a complete example with variable and function declarations. A similar complete example in another language is not likely to be _much_ more concise, unless you count shortening identifiers.

Overloading can be a useful thing. I just don't think it is be-all, end-all for the problem space, and I wanted to provide a second way the task could be done in C besides Charlie Gibbs's "easier to just cast" method.

I've been doing some Arduino programming recently, and while I'm writing C, it's clearly C++ overall because of the libraries I'm using, some of which are overloading stuff. One of those does things I find awkward because it tries to invoke the int method at times I don't want. Eg it wants zero to be the ASCII zero instead of ASCII null unless I write it as "byte(0)".

Elijah

------ has been tempted to rewrite the library

It's a common construction in human-generated assembly as well, at least on the PDP10.

Instead of

BAR: [do bar stuff] PUSHJ P, FOO POPJ, P

One writes

BAR: [do bar stuff] JRST FOO

and lets the POPJ at the end of FOO return from the call to BAR. Saves an instruction. In PDP10 land, the mnemonic PJRST is defined to be the JRST instruction in order to alert the reader of this intention, so one would write

BAR: [do bar stuff] PJRST FOO

Similarly, routines will often pop (restore) saved registers off the stack before returning. Rather than duplicate that code, one uses a PJRST to a label in another routine that does the same thing.

BAR: PUSH P, T1 PUSH P, T2 [do bar stuff] TPOPJ2: POP P, T2 TPOPJ1: POP P, T1 POPJ P,

FOO: PUSH P, T1 PUSH P, T2 [do foo stuff] PJRST TPOPJ2

On Tue, 5 Jan 2021 20:20:27 +0000, gareth evans declaimed the following:

You haven't looked at Ada, which uses the return type and the argument types to determine which variant of a procedure is to be invoked. And may OOP languages may also support such when overloading/overriding a parent's method.

On Thu, 7 Jan 2021 04:07:05 +0000, The Natural Philosopher declaimed the following:

I did X-Window some 30 years ago (DECWindows variant). I'm talking base X-Toolkit level, no such thing as KDE/GTK/wxWindow....

Even worse, I had to have the X-Window code invoke Graphical Kernel System code for the actual data display (I needed a Display List capability as the application was replacing a Ramtek 9300 graphics engine, AND the controlling application(s) were run as separate processes -- one would be responsible for drawing the axes&labels, one would draw colored boxes based upon data read from a large file, one handled creation of rubber band regions for filtering said data... And screen refreshes had to be possible without rerunning the original data processes (could take 15-30 minutes just to read the data file for the colored boxes, and among refresh events was "turning layers on/off" -- like the axes could be hidden, the rubber band triggered a refresh each time a line segment was confirmed).

On Wed, 6 Jan 2021 08:25:33 -0000 (UTC), Martin Gregorie declaimed the following:

LINKAGE SECTION was part of the COBOL-74 standard, and I recall it existed on the Xerox Sigma-6 COBOL that was used at my college when I attended (76-80). Our assignments may not have used it -- or we only had a short intro to the concept.

However, I'm fairly certain my college compiler did not support "copy books"... And since that time-frame meant 24x80 text terminals, and line mode text editors, one would have to manually duplicate the section from a listing... Or write the program on the IBM 029 card punch -- feeding the linkage section into it in duplicate mode, then inserting the copy into the second file...

Looks entirely reasonable to me, once you accept that == means "evaluates to" and === means "is". That can be a useful distinction, and often a necessary one in loosely typed languages.

Ah right, you already covered what I said.