Return to “Dev Logs”

Post

Re: [Adam] Thursday, February 15, 2018

#76
bdav wrote:
Thu Feb 22, 2018 3:31 am
AdamByrd wrote:
Mon Feb 19, 2018 10:28 am
My ideal language would contain (at least):
...
Adam, your wish list strongly reminds me of Rust ;)
I didn't know about Jai, it looks nice! Especially the automatic structure-of-arrays. But I have to disagree with that philosophy for any large project:
Programmers do make mistakes and cause crashes, perhaps even serious ones, but the argument is that the increase in productivity and reduction of friction when memory-safe mechanisms are absent more than make up for the time lost in tracking down errors, especially when good programmers tend to produce relatively few errors.
Adam actually already knows about Rust, and says it appears to have some nice ideas. :) Good call!
Have a question? Send me a PM! || I have a Patreon page up for REKT now! || People talking in IRC over the past two hours: Image
Image
Image
Post

Re: [Adam] Thursday, February 15, 2018

#77
Programmers do make mistakes and cause crashes, perhaps even serious ones, but the argument is that the increase in productivity and reduction of friction when memory-safe mechanisms are absent more than make up for the time lost in tracking down errors, especially when good programmers tend to produce relatively few errors.
... is this trying to argue that not being intrinsically memory safe makes a programming language faster to write in?
Are they mad?
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

#78
Flatfingers wrote:
Thu Feb 22, 2018 12:02 pm
Seems like designing a computer language for "good programmers" is an excellent way to insure that it remains a niche boutique language.

Nothing wrong with that, unless one of your goals is a self-sustaining population of users.
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.

I generally think the "self-sustaining population" of programmers right now is in a bad place. Most code is slow. Most code is riddled with bugs. Companies have insane numbers of programmers and end up being less productive than some teams of far fewer people.

So I'm looking at 'writing a language for experts won't be able to sustain the number of programmers we're used to' as a criticism and I'm not confident that's a bad thing. At the very least, I'm sure there are fundamental changes programming needs to go through to be a more productive industry as a whole and I think there's a chance Jai might be a step in the right direction.

Dinosawer wrote:
Thu Feb 22, 2018 1:24 pm
... is this trying to argue that not being intrinsically memory safe makes a programming language faster to write in?
I think the line of reasoning that leads to this statement is this: memory safety is achieved by limiting the set of things a programmer can do. That loss of control impairs the productivity of programmers who use the extra control wisely. Therefore, memory safe languages slow good programmers down.
Post

Re: [Adam] Thursday, February 15, 2018

#79
AdamByrd wrote:
Thu Feb 22, 2018 2:48 pm
Flatfingers wrote:
Thu Feb 22, 2018 12:02 pm
Seems like designing a computer language for "good programmers" is an excellent way to insure that it remains a niche boutique language.

Nothing wrong with that, unless one of your goals is a self-sustaining population of users.
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.

I generally think the "self-sustaining population" of programmers right now is in a bad place. Most code is slow. Most code is riddled with bugs. Companies have insane numbers of programmers and end up being less productive than some teams of far fewer people.

So I'm looking at 'writing a language for experts won't be able to sustain the number of programmers we're used to' as a criticism and I'm not confident that's a bad thing. At the very least, I'm sure there are fundamental changes programming needs to go through to be a more productive industry as a whole and I think there's a chance Jai might be a step in the right direction.
In my experience it seems a single good PR person is worth a LOT more than a couple of non-good PR people.


I am specifically thinking of you saying that the launch of LT is this year.

viewtopic.php?p=159527#p159527
Post

Re: [Adam] Thursday, February 15, 2018

#80
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
While I generally agree that a true professional and an inspired, confident and knowledgeable worker makes a world of difference - in fact, makes all the difference - it's not the tools that make your performance good, but the ability to make wonders with the limited set of tools you were given, and your capacity to find elegant solutions to stupid limitations imposed upon you.

In Procedural Reality, you are mostly fighting against the framerate. You squeeze every ounce of performance out of your code. And that's not a mainstream programming experience, and, in fact, neither it is a very common one.

In the rest of the world, managers decide which set of tools you have, and which set of limitations you need to overcome - and those people are not even coders most of the time, but bean counters and ticket-punchers.

On the other hand, I can't help but quote my father (who is not a coder): "Programmers are like children. They might be 40 years old, but they still don't know how to communicate ideas properly, or how to follow the deadlines, or how to actually organise work properly. Left to their own devices, they won't produce anything, because they don't know anything."

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.

And finally,

Image
Image
Survivor of the Josh Parnell Blackout of 2015.
Post

Re: [Adam] Thursday, February 15, 2018

#81
AdamByrd wrote:
Thu Feb 22, 2018 2:48 pm
I think the line of reasoning that leads to this statement is this: memory safety is achieved by limiting the set of things a programmer can do. That loss of control impairs the productivity of programmers who use the extra control wisely. Therefore, memory safe languages slow good programmers down.
yes, in a team of 20+ with unmanaged pointers and one changes a detail about how he handles his pointer access and suddenly random errors pop up all over the software and nobody knows why.

yes, totally safe and accelerating.


also, my comic form answer on the whole "real programmers use raw memory exclusively!" topic
http://abstrusegoose.com/483
Image
Post

Re: [Adam] Thursday, February 15, 2018

#82
AdamByrd wrote:
Thu Feb 22, 2018 2:48 pm
Flatfingers wrote:
Thu Feb 22, 2018 12:02 pm
Seems like designing a computer language for "good programmers" is an excellent way to insure that it remains a niche boutique language.

Nothing wrong with that, unless one of your goals is a self-sustaining population of users.
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.

I generally think the "self-sustaining population" of programmers right now is in a bad place. Most code is slow. Most code is riddled with bugs. Companies have insane numbers of programmers and end up being less productive than some teams of far fewer people.

So I'm looking at 'writing a language for experts won't be able to sustain the number of programmers we're used to' as a criticism and I'm not confident that's a bad thing. At the very least, I'm sure there are fundamental changes programming needs to go through to be a more productive industry as a whole and I think there's a chance Jai might be a step in the right direction.

Dinosawer wrote:
Thu Feb 22, 2018 1:24 pm
... is this trying to argue that not being intrinsically memory safe makes a programming language faster to write in?
I think the line of reasoning that leads to this statement is this: memory safety is achieved by limiting the set of things a programmer can do. That loss of control impairs the productivity of programmers who use the extra control wisely. Therefore, memory safe languages slow good programmers down.
Excuse me?
Pardon me being blunt, but have you actually done some programming in a decent sized group on a very large commercial long-term project in a non-memory safe programming language?
(so no, I don't mean the three of you working on LT.)
Cause you're sure as hell not giving that impression.
I'll gladly give away all the things we can do with direct manipulation that we can't with other programming (which, so far, in RL application, has been pretty much nothing) for not having to debug memory errors because of a tiny mistake somewhere.
Because that means figuring out that a crash in function Y was actually caused by something in function X 5 functions ago, except only if you also run the job on data A before data B but then only if you run it on windows 7 or vista 64 bit and compile it with Visual 2015 but not 2017. Oh, you wanted to use a debugger? Good, it also only happens in a release build, have fun. Also it' s not actually a crash, it's just the function behaving in a way that shouldn't be possible and it doesn't give a decent warning or error because it's not memory safe so frak you, programmer, have fun figuring it out.

But no I guess we're just bad programmers for making the occasional tiny mistake in our 2800 files large, 1.7 million lines of code large C/C++ project.
Last edited by Dinosawer on Thu Feb 22, 2018 3:55 pm, edited 1 time in total.
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

#83
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.

I generally think the "self-sustaining population" of programmers right now is in a bad place. Most code is slow. Most code is riddled with bugs. Companies have insane numbers of programmers and end up being less productive than some teams of far fewer people.
Yeah, I think I'd probably reject your help if you offered it. I'd rather a "bad programmer" that actually knows how to work with someone else, thanks.
Games I like, in order of how much I like them. (Now permanent and updated regularly!)
Post

Re: [Adam] Thursday, February 15, 2018

#84
Wow, that's some unreal rejection.

> But no I guess we're just bad programmers for making the occasional tiny mistake in our 2800 files large, 1.7 million lines of code large C/C++ project.
You should realize that making mistakes in the present code is usually a direct result of your actions in the past. If the code is poorly written and error prone in general it severely impacts your ability to write bugfree code which in turn leads to more error prone code and the cycle continues. This adds up. If you only hire good programmers, enforce code practices, styles and code reviews then you might be able to avoid that. In this situation those programmers will be slowed down by languages like rust. Rust doesn't position itself as a language for good programmers, it's a systems programming language for everyone, so that you could hire a junior rust developer without him silently screwing up half of your program. Jai is positioned as a tool for already experienced people. Simple as that.
Post

Re: [Adam] Thursday, February 15, 2018

#85
DoctorGester wrote:
Thu Feb 22, 2018 4:08 pm
You should realize that making mistakes in the present code is usually a direct result of your actions in the past.
No it isn't. Someone mistyping something or failing to foresee a very specific situation in which bad things will happen has nothing to do with the already existing code.
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

#86
DoctorGester wrote:
Thu Feb 22, 2018 4:08 pm
Wow, that's some unreal rejection.

> But no I guess we're just bad programmers for making the occasional tiny mistake in our 2800 files large, 1.7 million lines of code large C/C++ project.
You should realize that making mistakes in the present code is usually a direct result of your actions in the past. If the code is poorly written and error prone in general it severely impacts your ability to write bugfree code which in turn leads to more error prone code and the cycle continues. This adds up. If you only hire good programmers, enforce code practices, styles and code reviews then you might be able to avoid that. In this situation those programmers will be slowed down by languages like rust. Rust doesn't position itself as a language for good programmers, it's a systems programming language for everyone, so that you could hire a junior rust developer without him silently screwing up half of your program. Jai is positioned as a tool for already experienced people. Simple as that.
because errors never happen and theres only 100% perfect programmers to trivially hire out there.

also, code reviews totally dont cost time, no?


also what dino said, keeping stuff reliable over some 15odd years isnt trivial :V
Post

Re: [Adam] Thursday, February 15, 2018

#87
> No it isn't. Someone mistyping something or failing to foresee a very specific situation in which bad things will happen has nothing to do with the already existing code.

So you are trying to argue you are both a good programmer and a programmer who mistypes things and fails to foresee things and your code reviewer is also like that?

> because errors never happen and theres only 100% perfect programmers to trivially hire out there.

Like I said the amount of errors happening directly correlates to the quality of your existing code and your skill.

> also, code reviews totally dont cost time, no?

Yes they do, are you trying to argue they are unnecessary? Didn't you just imply errors happen all the time?
Post

Re: [Adam] Thursday, February 15, 2018

#88
DoctorGester wrote:
Thu Feb 22, 2018 4:16 pm
Yes they do, are you trying to argue they are unnecessary? Didn't you just imply errors happen all the time?
no im not. but you have less stuff to work through when you have less error sources that can produce less complex errors.
DoctorGester wrote:
Thu Feb 22, 2018 4:16 pm
So you are trying to argue you are both a good programmer and a programmer who mistypes things and fails to foresee things and your code reviewer is also like that?
yes, because everyone is 20 years precient and knows what the guy who can barely walk yet needs when e gets to expanding on their work.
Post

Re: [Adam] Thursday, February 15, 2018

#89
DoctorGester wrote:
Thu Feb 22, 2018 4:16 pm
> No it isn't. Someone mistyping something or failing to foresee a very specific situation in which bad things will happen has nothing to do with the already existing code.

So you are trying to argue you are both a good programmer and a programmer who mistypes things and fails to foresee things and your code reviewer is also like that?
Why yes, yes I am! Because you know what, nobody is perfect, everybody makes mistakes and real life projects get so large and complex that it's literally impossible to foresee everything that could happen. That doesn't make me a bad programmer. I work fast, I produce good results, my code is clean and readable, and we get paid for what I do.
To give you an example, the error I had recently (which I didn't cause, just had to fix) was because apparently C allows you to call functions on deleted and freed objects. And it works fine 99.9 percent of the cases. Like why does that even work? How does that not crash in nearly all cases?
DoctorGester wrote:
Thu Feb 22, 2018 4:16 pm
Like I said the amount of errors happening directly correlates to the quality of your existing code and your skill.
No, it correlates to the complexity of the code. Being more complex is not something that is always avoidable, and good luck making sure something you did doesn't cause something to go wrong somewhere in over a million lines of code.
And "if you were good enough you'd make no errors"... yeaaaah, sure.
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

#90
DoctorGester wrote:
Thu Feb 22, 2018 4:16 pm
> No it isn't. Someone mistyping something or failing to foresee a very specific situation in which bad things will happen has nothing to do with the already existing code.

So you are trying to argue you are both a good programmer and a programmer who mistypes things and fails to foresee things and your code reviewer is also like that?

> because errors never happen and theres only 100% perfect programmers to trivially hire out there.

Like I said the amount of errors happening directly correlates to the quality of your existing code and your skill.
Incorrect on both counts.

Errors are a function of coffee consumption, number of lines, number of files, size of team, and depth of brackets.
There is no place in the function that defines skill. Because the best of programmers is still human, and their squishy meatsack they call a brain is prone to auto-correcting, making assumptions, and sending incorrect signals.

Just typing this I have made two dozen or more mistakes in my typing that I have manually corrected.
Now apply the same thing to your code, and eventually the number of mistakes you make is greater than your capacity to fix them on the fly.
Eventually something slips the cracks.

If it's obvious (like a missing semicolon) it gets fixed upon the next debug run.
If it's non-obvious, like == instead of === it might only get noticed after a few dozen attempts to find a very specific error that only occurs sometimes in some things, and is unpredictable.
°˖◝(ಠ‸ಠ)◜˖°
WebGL Spaceships and Trails
<Cuisinart8> apparently without the demon driving him around Silver has the intelligence of a botched lobotomy patient ~ Mar 04 2020
console.log(`What's all ${this} ${Date.now()}`);

Online Now

Users browsing this forum: No registered users and 17 guests

cron