Click Here
home features news forums classifieds faqs links search
6071 members 
Amiga Q&A /  Free for All /  Emulation /  Gaming / (Latest Posts)
Login

Nickname

Password

Lost Password?

Don't have an account yet?
Register now!

Support Amigaworld.net
Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
Donate

Menu
Main sections
» Home
» Features
» News
» Forums
» Classifieds
» Links
» Downloads
Extras
» OS4 Zone
» IRC Network
» AmigaWorld Radio
» Newsfeed
» Top Members
» Amiga Dealers
Information
» About Us
» FAQs
» Advertise
» Polls
» Terms of Service
» Search

IRC Channel
Server: irc.amigaworld.net
Ports: 1024,5555, 6665-6669
SSL port: 6697
Channel: #Amigaworld
Channel Policy and Guidelines

Who's Online
23 crawler(s) on-line.
 111 guest(s) on-line.
 0 member(s) on-line.



You are an anonymous user.
Register Now!
 amigakit:  13 mins ago
 OneTimer1:  26 mins ago
 Troels:  1 hr 28 mins ago
 Gunnar:  1 hr 43 mins ago
 Rob:  1 hr 48 mins ago
 zipper:  2 hrs 12 mins ago
 NutsAboutAmiga:  3 hrs 17 mins ago
 kolla:  3 hrs 29 mins ago
 Comi:  3 hrs 59 mins ago
 vox:  4 hrs 45 mins ago

/  Forum Index
   /  Amiga General Chat
      /  Commodore Amiga Global Alliance
Register To Post

Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 Next Page )
Poll : Commodore Amiga Global Alliance
Yes, I would Join! £30
Yes, for less
Maybe
No
Bad idea, I have a better one....
Pancakes!
 
PosterThread
Karlos 
Re: Commodore Amiga Global Alliance
Posted on 4-Oct-2022 8:59:20
#501 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4394
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@an_overeducated_idiot

Quote:
Trouble is, any sufficiently large C or C++ program becomes so complex that every programmer is rendered an idiot


A valid point, but tinged with a certain hubris...

Quote:
Trouble is, any sufficiently large program becomes so complex that every programmer is rendered an idiot


Fixed it for you. The implicit assumption being that somehow programs written in Rust will never suffer from this problem. Nothing written in Rust, or any other programming language, prevents logical bugs that manifest at runtime, no matter how hard a straight jacket it puts the developer in. In complex systems, logical bugs often have equally complex and frustratingly annoying side effects due to that complexity. You might be able to confidently proclaim that this frustrating emergent bug in your enterprise application that's making you haemorrhage money wasn't caused by an index out of bounds issue, but it's not going to get the actual problem fixed.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
bison 
Re: Commodore Amiga Global Alliance
Posted on 4-Oct-2022 15:28:14
#502 ]
Elite Member
Joined: 18-Dec-2007
Posts: 2112
From: N-Space

@an_overeducated_idiot

Quote:
On the other hand, making function parameters immutable by default strikes me as the right choice

I agree in the case of pointer and reference parameters. Other parameters types don't matter so much in a language with pass-by-value semantics, since the callee gets its own copy and can't mess up the state of the caller.

_________________
"Unix is supposed to fix that." -- Jay Miner

 Status: Offline
Profile     Report this post  
Karlos 
Re: Commodore Amiga Global Alliance
Posted on 4-Oct-2022 17:28:22
#503 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4394
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

The point made regarding vocabulary in rust was a pertinent one.
Calling immutables "variables" is plain silly. The key property if variables in every other programming language and in mathematics being their ability to vary.

Last edited by Karlos on 04-Oct-2022 at 05:28 PM.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
gonegahgah 
Re: Commodore Amiga Global Alliance
Posted on 4-Oct-2022 18:48:16
#504 ]
Regular Member
Joined: 5-Dec-2008
Posts: 148
From: Australia

@NutsAboutAmiga

Nice to see some meaty discussion.

Quote:
Where OO goes wrong, is when you add methods to set and get the data, that’s how make something simple a fast into something slow and horrible.


I'm guessing for C++ that objects within an executable don't suffer this as the code can simply compile an executable with direct getting and setting where that is able to be done. External objects however probably still need to go through actual method calls for getting and setting values.

Certainly a method call may require all the baggage of context changes from calling it and returning and may in some cases involve a search/hash or selection process to be gone through which further lengthens the process. Module calls require context changes as well of course and I believe functional executables do a lot of duplicating which most likely adds some processing time. So each approach has some overheads but OO can have a fair bit.

Further if there are multiple class levels then this can add to the number of context changes and there can in many instances be temporary habitation in classes that do no more than pass it down the hierarchy.

There are some ways to reduce these extraneous context changes but I'm not sure if they are implemented in any object models or not?

Also there are some techniques to help speed things up slightly in some case such as interfaces which should reduce the amount of searching.

BOOPSI with its standardised tag list implementation for getting and setting attributes can certainly add even more redundant cycles to setting and getting values. It certainly allows attribute setting to be more open ended and flexible but at what cost?

The main problem I have with most class implementations is the drive to try to fit so many features into objects to try to address as many needs as possible. I tend to favour a "small model" approach for objects where objects serve more concentrated purposes that can then be combined.

Trying to make an object do everything is a destination to despair. This also tends to create a situation where the exact same code is duplicated in multiple different classes which was one of the things that OO was supposed to eliminate; but doesn't really tend to.

This is also a consequence of the OO model where things have direct inheritance when things in the real world require parallel solutions. A persian may be a cat that may be a feline that may be an animal, and a poodle may be a dog that may be a canine that may be also an animal. But a monkey may have a tail and a human not so much and a kangaroo has a tail and a wombat not so much. But primates and marsupials can't specifically be said to have a tail or not so much.

So you end up with real world base implementation consideration issues. This is one of the primary causes of OO having difficulty in actually mimicking the factual world and causes a lot of implementation duplication that isn't supposed to exist.

It can be further highlighted with coding modules. As a preference I will write two similar modules rather than try to write a super module that does both. I will then drag out any identical code into sub-modules. The code is much easier to follow and has less maintenance issues. I have always found this to be the better choice. But when we go OO we tend to try to shove everything in!

As an aside, another thing I grew to have an issue with are single result functions which are the mainstay of many languages. Most provide an awkward workaround where you pass a structure to fill with return values. But, why force the need for a workaround?

There are many situations where multiple returns make sense. A common one is the getting of trigonometry values. When you get the sin of an angle you most often need to get the cos of the angle as well yet we most often have these as separate functions. As we know these are very slow functions and are involved in a lot of graphical rotation code.

However the processes that actually get sin or cos can, at very little extra cost, produce the corresponding value as well. Certainly a whole lot faster than calling both expensive functions separately almost cutting the time in half. So there should always be a sincos() function that returns both values without the need for an ugly workaround. Another example is any call that returns a co-ordinate. Again a structure needs to be provided to allow the return of both the x and y values (unless they are merged and then unmerged after return, which is another workaround). Why not just allow both values to be returned as a natural process which more accurately represents real life?

The main thing is that many times the promise does not meet the reality and we should perhaps step back and ask why, and then see if we can better represent reality in a meaningful fashion.

Too many times we take the way things are as being the only way they can be in the world of computers and I don't really believe that necessarily is the case.

If you take a look at living cells, every cell contains the entire program! Can we afford to do that with computing machines? At the current scale probably not to that degree. But it is the real world and, despite the inefficiency of that approach, in some situations it actually works better than our current tech does.

I'm not suggesting that we do that but it is interesting to see the ways that we gloss over how often our representations don’t really mimic real life.

But, back to the original quote. Yes, it can be inefficient, especially BOOPSI tags, but there are some things in this world that I don’t think could be completely coded without OO. But it is struggling to represent the real ‘real’ world and the question to ask is if the situation can be improved? More often we innocently overlook the things that it stops us from doing, and we trust that it is the intrinsic nature of things and we don’t then seek to question the merit of things.

Perhaps we should look at the things that we are being prevented from doing, due to entrenched nature of current implementations, and instead question if those foundations can be improved? Is there a way to make things that seem impossible, more straight forward?

Too much is taken as fundamentally elemental under the current systems. And we just accept it because it is what we know and have built upon. The main hope seems to be to develop AI to address deficiencies in our systems, which honestly in my opinion, won’t really be that efficient a solution.

Maybe we should just reimagine the systems themselves and make the effort to make them work more in a more useable fashion that will become a useful extension of ourselves rather than a hindrance.

Last edited by gonegahgah on 04-Oct-2022 at 06:55 PM.
Last edited by gonegahgah on 04-Oct-2022 at 06:48 PM.

 Status: Offline
Profile     Report this post  
Karlos 
Re: Commodore Amiga Global Alliance
Posted on 4-Oct-2022 18:58:45
#505 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4394
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@gonegahgah

Quote:
I'm guessing for C++ that objects within an executable don't suffer this as the code can simply compile an executable with direct getting and setting where that is able to be done


As with any small functions, these can be inlined. For a simple getter and setter this reduces to direct member accesses. Moreover, for C++ if the function is defined in the class directly, it will be inlined by default. If it needs a non inline version, for example someone takes a pointer to it, the compiler is free to create one.

Quote:
real world require parallel solutions. A persian may be a cat that may be a feline that may be an animal, and a poodle may be a dog that may be a canine that may be also an animal. But a monkey may have a tail and a human not so much and a kangaroo has a tail and a wombat not so much. But primates and marsupials can't specifically be said to have a tail or not so much.


When the only tool you have is inheritance you can of course tie yourself up in some OCD classification cycle. Multiple inheritance is an interesting solution for some cases but it requires planning and discipline not to create a rigid lattice of relationships.

In my view the solution here is to go beyond and use compositional patterns in conjunction with inheritance. A concrete class composed of abstract parts, constructed by a builder or factory with appropriate concretisations for each part can replace the need for many otherwise redundant interim types. You can always then create specific derivations of the composition that have any necessary preset configuration of those parts if you want to have a named instance of something.

Last edited by Karlos on 04-Oct-2022 at 07:19 PM.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
Karlos 
Re: Commodore Amiga Global Alliance
Posted on 4-Oct-2022 19:28:23
#506 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4394
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@gonegahgah

On a different note...
Quote:

sin/cos


Go's multiple return is nifty for such things. In C++ you could probably afford to return a pair instance by value without too much overhead. Or failing that, you could use reference parameters for your results. For inline functions this often results in elimination of any indirection implied by the reference.

Quote:
As we know these are very slow functions and are involved in a lot of graphical rotation code


They aren't used as much as you might think. Usually for graphics you'd use them when setting up a transformation matrix of some kind to do the actual rotation on masses of points using basic multiply/accumulation operations. So a handful of calls to sine and cosine may result in the rotation of millions of vertices.

They are also interesting functions to approximate, depending on how much accuracy you need. A simple Taylor expansion can give a great approximation for a constrained input range, in just a couple of terms, again using nothing but multiply and accumulation type operations.

Last edited by Karlos on 04-Oct-2022 at 07:34 PM.
Last edited by Karlos on 04-Oct-2022 at 07:29 PM.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
NutsAboutAmiga 
Re: Commodore Amiga Global Alliance
Posted on 4-Oct-2022 20:40:09
#507 ]
Elite Member
Joined: 9-Jun-2004
Posts: 12795
From: Norway

@gonegahgah

I don’t think of OO as something that should represent the real world, when Apple designed their UI, the started in compered setting, so adapted language that describe a work environment trying to apply it to UI. Concept of application. It used lot heritage to describe some kind hierarchy, that was essentially meaningless in pre multiuser OS. And class won’t actually provide security level, the actual application was not written in application class or workers class, or management class, but in documentation class. What an ugly mess.

No you always should be data driven, what inputs do you have, how to present it, and what to access the data, in the least complex why, doing most in fewest possible steps.

Sound easy, but what is actually the fewest possible steps. Find things is common, that can be done once instead of doing every time, or only sometimes, figuring out to as early as possible some code is a waste of time to run, optimizing for most likely outcomes, or idea that bad throw away your instruction cache, you want if’s to be true more often than not. This complex thing is almost impossible keep in mind.

Last edited by NutsAboutAmiga on 04-Oct-2022 at 08:50 PM.
Last edited by NutsAboutAmiga on 04-Oct-2022 at 08:41 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

 Status: Offline
Profile     Report this post  
NutsAboutAmiga 
Re: Commodore Amiga Global Alliance
Posted on 4-Oct-2022 20:58:34
#508 ]
Elite Member
Joined: 9-Jun-2004
Posts: 12795
From: Norway

@gonegahgah

Quote:
Again a structure needs to be provided to allow the return of both the x and y values


Yes, but does need to be as parameter


struct xy
{
int,x,y;
};

struct xy func()
{
struct xy ret;
ret.x = 20;
ret.y = 40;
return ret;
}

void func2( struct xy &value )
{
if (ticks>20) { value.x =20; }
}


But passing the destination as reference, allows C++ not needing to move it from stack to the variable, theoretically. And what if you only need to change X, and not Y, is it a good idea to return x and y? most likely not.

Last edited by NutsAboutAmiga on 04-Oct-2022 at 09:03 PM.
Last edited by NutsAboutAmiga on 04-Oct-2022 at 09:02 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

 Status: Offline
Profile     Report this post  
Karlos 
Re: Commodore Amiga Global Alliance
Posted on 4-Oct-2022 21:03:24
#509 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4394
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@NutsAboutAmiga

Quote:
I don’t think of OO as something that should represent the real world


Well, only as far as anything in a computer doesn't represent the real world. However, as a way of organising software into reusable, modular components, it's useful. It's not the only way to do things and it's not always the best way to do things, it's just another tool in the box. Personally I find it useful as it forces me to think carefully about what I'm doing and think about which components I'll need.

As an example, MC64K's runtime is written in C++ and specifically requires the C++17. And yet, most of it is procedural and where it relies on memory allocation this is often using C library routines. Contrary to first glance, this isn't because I have no idea what I'm doing. There are only a handful of classes. The core interpreter could be written in C, with a few macros to assist making the register abstraction, which is basically a union type, more accessible. It doesn't make any significant use of any C++ features there. With C++17, I can make use of if constexpr and do compile time type checking that makes that part much cleaner at zero runtime cost. Similarly, using C++ initialiser types the host wrapper can be nicely templatised, primarily so that static construction as if it were a C structure is possible. It's essentially a static model so that the only dynamic allocation it needs is for the VM memory and raw binary object data from disk which is why it doesn't require much use of new, smart pointers or other features.

By contrast, the assembler itself was written in PHP and is heavily reliant on OO, with various parser abstractions, aggregations and so on. I chose PHP because it's amply fast enough for the job and has many powerful text processing features. It's also extremely quick to turn prototypes into functioning code. Even though, ice spent probably 80% of the total effort on that, and only 20% on the actual runtime.

Last edited by Karlos on 04-Oct-2022 at 09:09 PM.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
NutsAboutAmiga 
Re: Commodore Amiga Global Alliance
Posted on 4-Oct-2022 21:08:02
#510 ]
Elite Member
Joined: 9-Jun-2004
Posts: 12795
From: Norway

@Karlos

I see you quoted me, before I corrected my spelling.

Last edited by NutsAboutAmiga on 04-Oct-2022 at 09:08 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

 Status: Offline
Profile     Report this post  
NutsAboutAmiga 
Re: Commodore Amiga Global Alliance
Posted on 4-Oct-2022 21:16:25
#511 ]
Elite Member
Joined: 9-Jun-2004
Posts: 12795
From: Norway

@Karlos

Yeh, but PHP is so messy, Ruby on the other hand (if you’re going to pick a slow language.)

Won’t GO be the ideal language, for your stuff, its fast and also tries to be bullet prof. I found we pick languages we use, because it’s what we know. Fu*k I remember being scared to take on language as big as C, LOL, then on the other hand I used floppy disk at time. LOL.

Last edited by NutsAboutAmiga on 04-Oct-2022 at 09:17 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

 Status: Offline
Profile     Report this post  
Karlos 
Re: Commodore Amiga Global Alliance
Posted on 4-Oct-2022 21:18:17
#512 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4394
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@NutsAboutAmiga

Corrected. I don't think it changes my response though. When I was a lot younger, I was a typical OO zealot and having come to it via C++ used it obsessively. Then, as I matured (or just got older) I came to see that it's just a different way of organising software and there are many others, each with their own original aims, strengths and weaknesses. I really began to see the issues that arise with OO taken to extremes thanks to Java.

Today I like C++ because it's multiparadigm rather than it being OO in particular. I'm still something of a "C with classes" afficionado even though I do still appreciate the effort to make the language safer and more expressive overall.

Quote:

Yeh, but PHP is so messy, Ruby on the other hand (if you’re going to pick a slow language.)


Firstly, I chose PHP because I'm very familiar with it and I'm not with Ruby.

Secondly, you probably haven't used any recent iteration of PHP if you believe that it's still messy and slow. I mean, sure, it's not the cleanest language but nobody compels you to use gnarly old features. The maintainers do actively deprecate things and eventually remove them too. Not a bad feat for a language with such a large user base. As for speed, it's not a patch on native code when running interpretively, but can be much faster at imperative code when running under JIT. I've managed to trick the JIT engine into generating code about as performant as C, but generally it's still a lot slower. I don't know the state of the art for Ruby today, but when I last compared pre JIT PHP 7 to it, PHP was already a lot faster.

Last edited by Karlos on 04-Oct-2022 at 09:25 PM.
Last edited by Karlos on 04-Oct-2022 at 09:23 PM.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
Karlos 
Re: Commodore Amiga Global Alliance
Posted on 4-Oct-2022 21:31:18
#513 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4394
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@NutsAboutAmiga

Quote:
Won’t GO be the ideal language, for your stuff, its fast and also tries to be bullet proof


Possibly. There is a plan for a Go port. As for being bullet proof though, the very nature of the machine is dangerous. It doesn't abstract host memory, for example. If you have a value in one of the registers and then use it as an indirect address, it'll try to access that actual address. If this is an incorrect location, the engine will segfault (hopefully - maybe not if it's an address that the process owns, then some other random crap might happen).

Go may force changes that mean this is impossible, at the cost of performance, relative to the current implementation. Even so, that will be a worthwhile trade off in many people's opinion.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
bhabbott 
Re: Commodore Amiga Global Alliance
Posted on 5-Oct-2022 0:55:47
#514 ]
Regular Member
Joined: 6-Jun-2018
Posts: 330
From: Aotearoa

@Karlos

Quote:

Karlos wrote:
@bhabbott

Quote:
Evangelists of old insisted that C was the answer to everything


You could make the claim they were right, to be fair. The whole point of C was help make UNIX portable. It succeeded. Thanks to C, how many operating systems and applications do we have now that run on multiple platforms?

For the past 20 years I have been programming small microcontrollers. In the early days many MCUs didn't even have a C compiler. Then the C evangelists barged in and tried to replace all asm code with C. This required a lot of non-standard extensions that varied between compilers. It also created extreme bloat. I was working with 8 pin PIC MCUs that only had 512 words of ROM, 12 bytes of RAM and a 2 level return stack. And yes - you guessed it - developers who didn't want to learn PIC assembly language insisted on programing these chips in C! So Microchip was forced to supply a C compiler that 'worked' with them.

A few years later customers started complaining about not being able run Microchip's IDE on Linux, so they ported the code to Java (which blew it out to several Gigabytes). When experienced developers complained about how slow and clunky it was they ignored us. Atmel did something similar with their IDE. Then the Arduino people developed a simplified Java-based IDE for AVR using gcc, and C functions that traded speed for ease of programming (for 'people who aren't programmers').

Experienced developers would carefully read the MCU datasheets and create their own 'bare metal' code based on intimate knowledge of the hardware. But this wasn't good enough for the evangelists, who insisted on virtualizing everything with 'frameworks' that produced the code for you. ST are probably the most infamous, producing two different frameworks that were incompatible with each other and full of bugs. You spent more time trying to figure out how to use it and why it didn't do what it should than if you had just written all the code yourself from scratch.

Quote:
If it were possible to graph the total number of machine operations globally per day as a function of the programming language that generated said operations, you'd probably need to zoom in a long way to see anything not emanating from C code.

But we are zooming in a long way - all the way back to 1985 when the Amiga was born. Back then you didn't have to look far to see asm. MSDOS was written in it, and millions of PCs were running on it. Lotus 123 - the first 'killer' app for PCs - was written in asm. The vast majority of home computer operating systems and games were written in asm, and every user knew it was the answer for getting the necessary performance.

Calculating the number of 'machine operations' is tricky. Tiny MCUs running asm code are embedded in all kinds of things - from credit cards to USB sticks and SD cards, LCD displays, keyboards and mice etc. When your PC is turned 'off' many of these devices are still active. Then there are devices running industrial machines, traffic lights, lifts etc. that have been going for decades, many of them programmed at least partly in asm.

Any figure you come up with for global machine operations is going to be a guess. However one thing we do know is that Amiga's Exec is written in pure asm, and large parts of the OS were down-coded to asm for efficiency. So when using your Amiga you don't have to look far at all to see something not emanating from C.



Last edited by bhabbott on 05-Oct-2022 at 01:01 AM.
Last edited by bhabbott on 05-Oct-2022 at 12:59 AM.
Last edited by bhabbott on 05-Oct-2022 at 12:58 AM.

 Status: Offline
Profile     Report this post  
bhabbott 
Re: Commodore Amiga Global Alliance
Posted on 5-Oct-2022 1:44:46
#515 ]
Regular Member
Joined: 6-Jun-2018
Posts: 330
From: Aotearoa

@cdimauro

Quote:

cdimauro wrote:
@bhabbott
Quote:
The vast majority of modern cars have automatic transmissions, for the idiots right?

Wrong: for the people which like it or NEED it (injuries? You don't know how the real world is).

Ludicrous argument. Manufacturers don't put automatic transmissions in their cars for people who have injuries. If you are so injured that you can't operate the controls then you shouldn't be driving.

But you don't understand what I am saying. Many people today don't know how to drive a manual car, because they never had to. Similarly, many programmers can't write in C without making 'idiot' mistakes, because they never had to write much C code. And why should they? Just like modern cars are easier and safer to drive, so modern programming languages are easier to avoid making mistakes in - and that's a good thing.

Quote:
a very common logical fallacy. As usual, you show to lack elementary logic.

I'm perfectly able to switch from manual to automatic gear. So, definitely I'm not an idiot. Whereas you, for what you said yourself, are one (I'm just applying YOUR "logic").

It's not my logic. It's the logic of people who say only 'idiots' make mistakes in C.

Quote:
Totally wrong: you don't know what you talk about.

Why don't you just talk about assembly, since it seems to be the only language where you have some rough knowledge?

Says the person who doesn't know what he is talking about. I've written plenty of code in C on the Amiga, PC (Win16 and Win32), and MCUs (my last work project used an Arduino which I programmed in pure C). I just aren't arrogant enough to say that I never make mistakes - in any language. Heck, I make mistakes in asm all the time!

Quote:
I've already said it, but you don't understand because you're a stubborn dumbass: framed on you asm-only parallel universe (your cave)...

My man-cave is only for retro computing, and even there it isn't all asm.

I don't know where people got the idea that I am asm-only and reject all other languages. But the mere suggestion that I might enjoy programming retro computers in asm triggers the evangelists, who must stamp out all traces of it wherever they see it!

 Status: Offline
Profile     Report this post  
an_overeducated_idiot 
Re: Commodore Amiga Global Alliance
Posted on 5-Oct-2022 2:03:02
#516 ]
Member
Joined: 30-Sep-2022
Posts: 14
From: Somewhere south of the North Pole

@Karlos

I'm somewhat taken aback by your reply. I'm sorry if I came across as disingenuous; that was certainly not my intent. I spent a long time writing another reply, but concluded it would be counterproductive, and we would merely going in circles. I do think you should go back and read what I wrote, especially the industry studies I cited, but you apparently haven't so far, and I don't have anything to contribute beyond that, so I'll withdraw from the conversation.

Last edited by an_overeducated_idiot on 05-Oct-2022 at 02:05 AM.

 Status: Offline
Profile     Report this post  
Karlos 
Re: Commodore Amiga Global Alliance
Posted on 5-Oct-2022 6:44:32
#517 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4394
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@an_overeducated_idiot

There's no need to do that, I'm well aware of the uptake of rust in a number of large organisations. I assumed I'd sent the wrong signal that any language built on C can only be as "safe" as C. Obviously this is nonsense since all compiled languages reduce to the same object code in the end, so that would mean they're all only as safe as assembler.

Flip that around and you can see that ultimately assembler is as safe as any high level language when you write it with safety in mind. It's just a lot more challenging to do for a human than it is a compiler.

My view is that all (non esoteric) languages are safe when used correctly. Where they differ is in how much they allow you to do, how directly you can do it and as a consequence the effort required to stay "within" the definition of correct usage.

Robust conversation is what makes these topics fun and interesting.

Last edited by Karlos on 05-Oct-2022 at 07:07 AM.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
Karlos 
Re: Commodore Amiga Global Alliance
Posted on 5-Oct-2022 7:06:06
#518 ]
Elite Member
Joined: 24-Aug-2003
Posts: 4394
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

@bhabbott

Quote:
But the mere suggestion that I might enjoy programming retro computers in asm triggers the evangelists, who must stamp out all traces of it wherever they see it!


Well I may consider myself an evangelist for C dialects, yet on the contrary, MC64K was conceived solely as an excuse to write assembler style code for fun. A runtime written in a mixture of C and C++, tooling written in PHP so that someone can write something resembling assembler for a CPU that doesn't even exist outside of some feverish 90's dream.

Every new language has its evangelists and shills. Today it's Rust, yesteryear it was Java. It maybe because I'm older and grumpier that I find the Rust ones louder and more fun to wind up.

An exception may well be Go. It's just there, with people using it and getting on with stuff. There aren't long blog posts about how innately superior it is to all that crumble before it, hours of youtube content comparing it to 40 year old languages that are deadly just because they assumed practitioners would be careful or comparing them to 30 year old implementations of C++, etc.

In a few decades, Rust will be just another systems level language, living alongside Go, C++ and even C and some other language will be vying to displace them all.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
gonegahgah 
Re: Commodore Amiga Global Alliance
Posted on 5-Oct-2022 22:59:49
#519 ]
Regular Member
Joined: 5-Dec-2008
Posts: 148
From: Australia

@Karlos

Quote:
When the only tool you have is inheritance you can of course tie yourself up in some OCD classification cycle. Multiple inheritance is an interesting solution for some cases but it requires planning and discipline not to create a rigid lattice of relationships.

This can present in a couple of ways.
Just as a simple example, say we make a chain class and we wish to inherit from two chain classes to make a list class then how do you inherit from two identical classes. A dog inherits four legs afterall; not one.
I'll have to get back on the "diamond problem" because I can't remember if I had an answer or not.

Quote:
In my view the solution here is to go beyond and use compositional patterns in conjunction with inheritance. A concrete class composed of abstract parts, constructed by a builder or factory with appropriate concretisations for each part can replace the need for many otherwise redundant interim types. You can always then create specific derivations of the composition that have any necessary preset configuration of those parts if you want to have a named instance of something.

I was thinking that there may possibly need to be some sort of runtime class building if it is possible and worthwhile.

Quote:
Usually for graphics you'd use them when setting up a transformation matrix of some kind to do the actual rotation on masses of points using basic multiply/accumulation operations. So a handful of calls to sine and cosine may result in the rotation of millions of vertices.

Cool. After you mention it that sounds very true. I'm looking to write some 4Dspace code one day eventually (5D if you count time as an equal partner). Maybe they should call it 4sD+1tD?

Last edited by gonegahgah on 05-Oct-2022 at 11:00 PM.

 Status: Offline
Profile     Report this post  
gonegahgah 
Re: Commodore Amiga Global Alliance
Posted on 5-Oct-2022 23:19:19
#520 ]
Regular Member
Joined: 5-Dec-2008
Posts: 148
From: Australia

@NutsAboutAmiga

Quote:
I don’t think of OO as something that should represent the real world, when Apple designed their UI, the started in compered setting, so adapted language that describe a work environment trying to apply it to UI.

You're talking about skeuomorphism. No I didn't mean that.
I mean making things work as a useful extension of what you want to do rather than acting as an impediment. I find PCs often stop me from doing what I want to do in the way I want to do something. And I think this is a problem with the fundamental design.

Separately, there are examples where skeuomorphism would make sense such as if you wanted to create a virtual museum. Representing things as real world object in this scenario would make some considerable sense.

Quote:
No you always should be data driven, what inputs do you have, how to present it, and what to access the data, in the least complex why, doing most in fewest possible steps.

I don't disagree but I think objects are usually way overloaded making them less flexible.

Also, I get the feeling that not as much consideration has been given to objects with respect to how some need to output at times and not just input. They are not always the end of the action and are sometimes the middle man.

 Status: Offline
Profile     Report this post  
Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 Next Page )

[ home ][ about us ][ privacy ] [ forums ][ classifieds ] [ links ][ news archive ] [ link to us ][ user account ]
Copyright (C) 2000 - 2019 Amigaworld.net.
Amigaworld.net was originally founded by David Doyle