Return to “Dev Logs”

Post

Re: [Adam] Thursday, February 15, 2018

#122
AdamByrd wrote:
Thu Feb 22, 2018 9:59 pm
A pointer to what? Oh, a struct you say? So package up all the necessary data for a given type of operation, say, pathfinding and they write functions that operate on one or more data chunks? Hey look, you invented components!
And hey look, you can do it without an esoteric language!
Games I like, in order of how much I like them. (Now permanent and updated regularly!)
Post

Re: [Adam] Thursday, February 15, 2018

#125
AdamByrd wrote:
Thu Feb 22, 2018 10:44 pm
I missed the part where anyone at all said a specific language was required for a component architecture. At this point it's just unnecessary snark.
AdamByrd wrote:
Thu Feb 22, 2018 2:48 pm
In my experience it seems a single good programmer is worth quite a few non-good programmers. I think empowering the good ones has the potential to be a larger net benefit than hamstringing them to coddle the meh ones.
....
....
Do remember, you walked into the room yelling at people :) Dont complain when you get told to sit down and listen.

Btw, you still havnt answered the question about the launch date.

Now that you have decided that this current coding debate is just unneccessary snark. Perhaps you could turn your mind to that question?
Post

Re: [Adam] Thursday, February 15, 2018

#126
Well. That escalated quickly. :lol:

At the risk of getting what's left of my hair singed off:

1. I've been a working programmer for half my career and a project manager the other half. I've written real code that does real stuff in a minimum of three languages (including a game my wife plays every day, and she's a perfectionist) and I've written useful working programs in at least half a dozen more languages. I've worked "lone wolf" and in teams with Much Process. So I feel like I've got a reasonable set of experience with seeing programming from different angles, primarily as a down-in-the-trenches, I-will-not-let-the-language-beat-me coder and as someone responsible for the scheduled development and long-term maintenance of high-criticality software systems. So there are some bona fides. The rest of what follows is based on this experience, and on reading the thoughts of others (e.g., Gerald Weinberg and Fred Brooks) about this stuff both for fun and for professional development, and on trying to think carefully about it.

2. Natural programming ability is probably on a bell curve. A few are really bad; a few are superstars; some are incompetent; some are excellent; by far the majority of programmers who span the full range of what programmers do are simply competent.

3. Context matters. Not all coding requirements are equal; some products are harder to code than others. Programmer skill is not irrelevant to context.

4. It is entirely a Good Thing that lots of new programming languages are created! I strongly endorse lots of creative effort in imagining new ways of expressing functional requirements as software.

5. A well-designed programming language takes into account both the intended operational context and the typical skill level of its likely practitioners. A language for writing single-function programs on which human lives depend (think the Apollo Guidance Computer software or the HUD of a jet fighter) has different design characteristics, and will typically be used by highly-skilled programmers, than a language whose primary value characteristic is that programs written in it are easy to understand and maintain over several decades by junior and average-skill programmers.

So adding all this up, when we talk about designing a new computer language, I don't believe there's a single metric for deciding the quality of that language. I think you have to take into account the context in which that language will be used (specific or general-purpose) and -- connected to context -- the typical skill level of the people you want to be able to productively use that language.

If it's a special-purpose language that's meant to allow superstar coders to blast out massive amounts of working code quickly, that's 100% fine. We can discuss what kinds of features a language like that ought to have. It's important to understand that a language like this will never be popular enough to be self-sustaining -- the developer(s) will have to actively support it in some way, either personally or by making a deal with some institution. That's the price for targeted performance.

If it's a general-purpose language that's meant to be easily comprehensible by the average coder, then that calls for a different set of evaluation criteria. We can also discuss what kinds of features a language like this ought to have... but it's equally important to understand that the tradeoff for comprehensibility is usually performance. There is also nothing inherently wrong with this.

To sum up, then, I'm saying that a general-purpose language is probably better if it has features that protect average-skilled coders from themselves. Absolutely you pay a performance price for things like static typing and garbage collection... but if your intended context is business software, then that cost is almost certainly paid for in the value of fewer hours wasted hunting down conversion bugs and null pointers. Conversely, if your intended context is more specific -- such as, oh, I don't know, a game engine, maybe? ;) -- then there may be more value in removing the safeguards and depending on the greater skill level of the language's likely coders to avoid errors.

To put it another way, if all the developers supporting my long-term software projects were as good as the Procedural Reality team members, I'd support a high-performance, low-controls language as a general programming language.

But they aren't. So I don't.
Post

Re: [Adam] Thursday, February 15, 2018

#127
> If it's a special-purpose language that's meant to allow superstar coders to blast out massive amounts of working code quickly, that's 100% fine. We can discuss what kinds of features a language like that ought to have. It's important to understand that a language like this will never be popular enough to be self-sustaining -- the developer(s) will have to actively support it in some way, either personally or by making a deal with some institution. That's the price for targeted performance.

Keep in mind that there is already a whole industry using C++ which is in no way an easier language than Jai.

Also I don't think there was initially any point about one language being strictly better than the other and like I said, Rust is targeted for a wider audience which is totally fine. A smaller audience of more experienced people might be able to do more work using Jai, instead. Which is alright.

Also you don't pay for static typing in runtime costs, it's quite the opposite usually. Unless you are Java and typecheck every function call in the runtime as well.
Post

Re: [Adam] Thursday, February 15, 2018

#129
AdamByrd wrote:
Thu Feb 22, 2018 5:15 pm
outlander wrote:
Thu Feb 22, 2018 3:11 pm
If you disagree, try writing specialised software (military, security, industrial) and you'll find out that you'll be hampered not by the programming tools, but by your lack of knowledge of the processes involved.
Eh, I've worked on training simulations for oil refineries, military training, and HPC physics stuff. Sure, it's not like I've been knee deep in that stuff for 2 decades, and yes getting up to speed on some of their processes takes time, but looking back I can't honestly say that was the largest time sink. And it certainly didn't dominate enough to say tooling improvements aren't a worthwhile investment.
And that's precisely why most specialised software is so atrocious. Working on it is...well, it's not a nightmare, but it's annoying to the point of starting to pull my hair out. It made me wish to be able to write decent code myself just to make something that makes sense for a given workflow (mostly microscopy in my case...and you'd think Leica would have figured that out over several decades :ghost: ). It's like it was designed and written by people who never did any serious amount of work with a microscope in their entire life - and I'm not talking purely about the UI, but also some fundamental limitations like absent or awful batch processing, absolutely atrocious input/output for files, and a custom system for microphotograph attributes that makes me process files one at a time at a snail's pace, all the while suffering from memory leaks.

In my experience, the best specialised software is written by people who actually had experience in the given field, and the worst one is written by large commercial entities. Of course, the former usually lack in functionality, so you have to use the latter even if it makes you cringe and die inside every time you start it up.
Image
Survivor of the Josh Parnell Blackout of 2015.
Post

Re: [Adam] Thursday, February 15, 2018

#131
Selecting text, copy, reply, type >, paste is easier than clicking a button?
Okay ¯\_(ツ)_/¯
I mean even if you hate doing it that way, you could at least ad

Code: Select all

[quote][/quote]
around the quoted part to make it readable (select text, click button Quote in reply window)
Warning: do not ask about physics unless you really want to know about physics.
The LT IRC / Alternate link || The REKT Wiki || PUDDING
Image
Post

Re: [Adam] Thursday, February 15, 2018

#133
DoctorGester wrote:
Fri Feb 23, 2018 5:25 am
Yeah I just found out the quote behavior is different on the reply page, ugh... I tried selecting text and pressing quote before but it just brought me to the reply page with full text quoted. See, this is why the world needs more UX professionals.
Or perhaps what is needed? Is people, to stop making assumptions before they have actually checked.
Last edited by Naed on Fri Feb 23, 2018 6:58 am, edited 1 time in total.
Post

Re: [Adam] Thursday, February 15, 2018

#134
DoctorGester wrote:
Fri Feb 23, 2018 5:25 am
Yeah I just found out the quote behavior is different on the reply page, ugh... I tried selecting text and pressing quote before but it just brought me to the reply page with full text quoted. See, this is why the world needs more UX professionals.
What the world needs is less people who can't figure out how BBCode works.
Image
Survivor of the Josh Parnell Blackout of 2015.
Post

Re: [Adam] Thursday, February 15, 2018

#135
DoctorGester wrote:
Fri Feb 23, 2018 5:04 am
Yeah no quoting on this forum is terrible UX honestly (no offense, I'm guessing this is vbulletin's or whatever engine it uses fault), just as replying in general. My way feels easier to me...
And this is exactly the problem.

You have "your way" of doing things. We would very much not like "your way" of doing things forced upon us, because we very much feel that "our way" of doing things is much easier and more productive.

You've shown that the Quote button isn't necessary to be able to quote people. Should we just remove it to improve the loading times of the forum? Anyone who can't quote without it is obviously just a bad forum user anyway, and a single good forum user is worth quite a few bad forum users...
Games I like, in order of how much I like them. (Now permanent and updated regularly!)

Online Now

Users browsing this forum: No registered users and 2 guests

cron