Saving the World from Code

HardwareGeek

@scholrlea said in Saving the World from Code:

Anyway, all of this is ignoring something known to be a major problem with specifications: they change.

Not to mention vague, incomplete, and sometimes just plain wrong.

dkf

@blakeyrat said in Saving the World from Code:

How about we get secure software, and you can make a Stored Procedure to do the weird-ass shit you like.

How many stories have we had round here about stored procedures doing weird unsafe shit? Too bloody many (unless they name and shame ;)). Yet for all that, there remain cases where that sort of thing is actually the right thing to do; there's often things that can't be done any other way (such as where the table name needs to be generated at runtime, which is really awful but sometimes required anyway…)

Jaloopa

@dkf said in Saving the World from Code:

the table name needs to be generated at runtime

    Public Function GetSingleValueFromDatabase(table As String, column As String, condition As String, connectionStringSource As String) As Object
        Using connection As SqlConnection = New SqlConnection(ConfigurationManager.ConnectionStrings(connectionStringSource).ConnectionString)
            connection.Open()
            Dim query As String = "SELECT " & column & "FROM " & table & "WHERE " & condition
            Using command As SqlCommand = New SqlCommand(query, connection)
                Return command.ExecuteScalar
            End Using
        End Using
    End Function

Zecc

@dkf said in Saving the World from Code:

How many stories
have we had round here
about stored procedures
doing weird unsafe shit?

The answer my friend
is blowin' in the wind.
The answer is blowin'
in the wind.

dkf

@jaloopa Bug: column and table names are concatenated onto the following keyword.

Jaloopa

@dkf You're right. Hang on a second...

    ''' <summary>
    ''' gets some data from a table or some shit
    ''' </summary>
    ''' <param name="table">the table to select from. Must end in a space</param>
    ''' <param name="column">The column to select from. Must end in a space</param>
    ''' <param name="condition"></param>
    ''' <param name="connectionStringSource"></param>
    ''' <returns>the value you wanted. Hopefully</returns>
    Public Function GetSingleValueFromDatabase(table As String, column As String, condition As String, connectionStringSource As String) As Object
        Using connection As SqlConnection = New SqlConnection(ConfigurationManager.ConnectionStrings(connectionStringSource).ConnectionString)
            connection.Open()
            Dim query As String = "SELECT " & column & "FROM " & table & "WHERE " & condition
            Using command As SqlCommand = New SqlCommand(query, connection)
                Return command.ExecuteScalar
            End Using
        End Using
    End Function

There. Much better

Scarlet_Manuka

@jaloopa said in Saving the World from Code:

There. Much better

Yes, but you can't trust the user to do it right. So you should declare private variables to shadow the user's input and automatically append a space, and then use the private variables to construct the query.

Also, the query optimiser won't be able to recognise the statements as being the same if they have different amounts of space in it, so before you run the statement you should do a replace-all on it to replace multiple spaces with a single space. That way a cached execution plan can be used if we've seen the statement before, regardless of whether the user remembered to put in the spaces or not.

boomzilla

@blakeyrat said in Saving the World from Code:

@boomzilla said in Saving the World from Code:

No, sometimes those kinds of things make sense. Especially when you're dealing with outer joins. But seriously, are all of the things in your where clauses always coming from dynamic sources / user input? It sounds like you have some very simple queries to me, if that's the case.

How about we get secure software, and you can make a Stored Procedure to do the weird-ass shit you like.

Ugh. Stored procedures suck. That would be even worse. You could just have sane clients like I do and it won't be a problem.

boomzilla

@djls45 said in Saving the World from Code:

@boomzilla said in Saving the World from Code:

If my business users tried to get into the business of dictating data types I would start some fights.

... just because Oracle doesn't let you distinguish between empty string and null.

Ah, another challenger arises?

Kian

“Typically the main problem with software coding—and I’m a coder myself,” Bantégnie says, “is not the skills of the coders. The people know how to code. The problem is what to code. Because most of the requirements are kind of natural language, ambiguous, and a requirement is never extremely precise, it’s often understood differently by the guy who’s supposed to code.”

On this view, software becomes unruly because the media for describing what software should do—conversations, prose descriptions, drawings on a sheet of paper—are too different from the media describing what software does do, namely, code itself. Too much is lost going from one to the other. The idea behind model-based design is to close the gap. The very same model is used both by system designers to express what they want and by the computer to automatically generate code.

These two paragraphs struck me because the guy correctly diagnosed the problem, then completely failed on the solution. "Because requirements are ambiguous, let's make a tool that requires perfectly defined requirements." That's what programming languages are. The problem is coming up with the perfectly defined requirements, and changing the programming environment does little to help on that aspect when the stake holders themselves don't know what they want.

The thing non-programmers usually fail to understand is that turning requirements to code is the easiest part of programming. It's knowing what you want to happen in response to any particular event and how all that interacts with other requirements that's the problem.

blakeyrat

@boomzilla said in Saving the World from Code:

Ugh. Stored procedures suck. That would be even worse. You could just have sane clients like I do and it won't be a problem.

The real point is, we've figured out long ago that "just trust the programmer to do the right thing" strategy does not work. It's great that you're the 0.5% of programmers who reads the specs and writes safe code, but we need a solution for the 99.5%.

boomzilla

@blakeyrat said in Saving the World from Code:

@boomzilla said in Saving the World from Code:

Ugh. Stored procedures suck. That would be even worse. You could just have sane clients like I do and it won't be a problem.

The real point is, we've figured out long ago that "just trust the programmer to do the right thing" strategy does not work. It's great that you're the 0.5% of programmers who reads the specs and writes safe code, but we need a solution for the 99.5%.

Yes, and I already gave one that's much better than the nuking literals from orbit like @masonwheeler proposed. Comments and semicolons are errors.

blakeyrat

@boomzilla said in Saving the World from Code:

Comments and semicolons are errors.

You can do SQL injection, at least in MS SQL Server, without either of those.

select accountName, emailAddress
from users
where userId = 34762746327;

!!! INJECT 0 OR 1 = 1!!!

select accountName, emailAddress
from users
where userId = 0 OR 1 = 1;

YOU'VE JUST LEAKED ALL YOUR EMAILS!

And look we didn't even touch the semicolon.

heterodox

@blakeyrat said in Saving the World from Code:

You can do SQL injection, at least in MS SQL Server, without either of those.

Indeed you can do SQL injection anywhere without either of those.

boomzilla

@blakeyrat said in Saving the World from Code:

@boomzilla said in Saving the World from Code:

Comments and semicolons are errors.

You can do SQL injection, at least in MS SQL Server, without either of those.

I asked a question above (or made an assertion that no one challenged) regarding how often injection used those. Obviously it's possible, but much more difficult and probably less effective.

blakeyrat

@boomzilla said in Saving the World from Code:

I asked a question above (or made an assertion that no one challenged) regarding how often injection used those. Obviously it's possible, but much more difficult and probably less effective.

I don't read every fucking post. We're using this stupid forum software that if you click a response in the notifications, it LOSES your nominal unread marker.

Whatever.

The real point is that development environments should be as safe as humanly possible and if that hurts "super-mega-expert-man-Boomzilla who never gets anything wrong" then, well, TOUGH SHIT because there are virtually none of those people.

The guy at Apple who typed in goto fail; goto fail; was probably really smart. It didn't save him from making a huge security blunder a better language or IDE or testing process would easily have prevented. But no; he was typing in an obsolete language in a fucking plain text editor so everybody suffered.

The difference between software developers and professionals is that professionals know they sometimes make mistakes and put in protections to prevent that, while software developers use fucking VI in 2017 to write C code because they're horrible.

japonicus

@blakeyrat said in Saving the World from Code:

The real point is, we've figured out long ago that "just trust the programmer to do the right thing" strategy does not work. It's great that you're the 0.5% of programmers who reads the specs and writes safe code, but we need a solution for the 99.5%.

Mandatory taint tracking would go quite a long way to solving injection problems without crippling constraints on sql usage, but too few languages have built-in support.

djls45

@zecc said in Saving the World from Code:

@dkf said in Saving the World from Code:

How many stories
have we had round here
about stored procedures
doing weird unsafe shit?

The answer my friend
is blowin' in the wind.
The answer is blowin'
in the wind.

I fail to understand how expelling breath into the air is an answer to anything "important" (like the questions the song asks). ( :P )

boomzilla

@blakeyrat said in Saving the World from Code:

The difference between software developers and professionals is that professionals know they sometimes make mistakes and put in protections to prevent that, while software developers use fucking VI in 2017 to write C code because they're horrible.

Yeah. That sounds about as dumb as using git as backup software,

blakeyrat

@boomzilla said in Saving the World from Code:

Yeah. That sounds about as dumb as using git as backup software,

Fine; it's stupid as fuck.

Self-delusion is equally stupid, though, and far more dangerous. Mr. "There's No Way To Do SQL Injection If You Filter Out Semi-colons And Comments".

Unlike you, my interest isn't in "not doing stupid things", it's in having good solid high-quality software. If the best method of doing turns out to be standing on your head while humming Bolero, then fucking get those feet in the air buddy and click this link.

boomzilla

@blakeyrat said in Saving the World from Code:

Self-delusion is equally stupid, though, and far more dangerous. Mr. "There's No Way To Do SQL Injection If You Filter Out Semi-colons And Comments".

Don't put words into my mouth that I never said.

@blakeyrat said in Saving the World from Code:

Unlike you, my interest isn't in "not doing stupid things", it's in having good solid high-quality software.

Don't put words into my mouth that I never said.

blakeyrat

@boomzilla said in Saving the World from Code:

Don't put words into my mouth that I never said.

Oh; right. That's the thing I'm doing now apparently. I forgot for a second.

Dreikin

@blakeyrat said in Saving the World from Code:

@scholrlea The problem wasn't the speed, the problem was that the wind blew at a steady rate for a long period of time. The bridge was perfectly safe when there were gusting, random winds... it was when the wind didn't change direction or speed for a long period of time that it began to oscillate.

@dreikin said in Saving the World from Code:

I know the Tacoma Narrows one. What (if any) are the other references?

@dreikin said in Saving the World from Code:

"I'm sure that the connection between these hanger rods whose layout we changed for aesthetic reasons, and the box girders we redesigned for aesthetic reasons, can hold the load; no reason to re-calculate that"

This was a second store balcony collapsing at a shopping center. (Can't remember the name exactly.)

Also the box girders bit might refer to the emergency Citicorp Center repairs back in 1978, where an engineering student realized that a (supposedly) harmless change made during construction resulted in the building's wind resistance being far less than designed, and the architect had to repair it before a tropical storm landed in New York.

@dreikin said in Saving the World from Code:

"Hey, this procedure of using a forklift when re-attaching the engine nacelles in a process requiring millimeter precision works great and saves a ton of time, let's tell everyone else about it, but don't bother writing it down or anything"

I've read about that one but I can't remember the flight number.

EDIT: American Flight 191.

@dreikin said in Saving the World from Code:

"Ah, what harm could there possibly be in going six months between times lubricating the tail section's elevator jack screws rather than the mandated six weeks?"

Alaska Flight 261. The jackscrew wore-down faster than anticipated because the maintenance team: 1) didn't lubricate it enough, and 2) didn't open it up to inspect it often enough. Notable because the pilots tried everything to get that broken heap on the ground, including attempting to fly it upside-down when they realized there was no other way to get its nose up. They failed, but still a pretty amazing story.

@dreikin said in Saving the World from Code:

"sure, you can just slide those 20 ton air conditioning units across the roof, no need for a crane or even rollers"

That was a shopping center somewhere in Asia... China? Pretty self-explanatory, an incompetent crew was installing hugely heavy air conditioning units without checking that the building was rated for the weight, and without using the proper equipment to place it.

Thanks :)

dkf

@blakeyrat said in Saving the World from Code:

You can do SQL injection, at least in MS SQL Server, without either of those.

This sort of thing is why database access code needs to be always run past a sneaky senior developer before going to a mainline branch. The problem isn't the presence of comments, or semicolons, or constants. The problem is doing string substitutions to make SQL with values coming from an untrusted source, and it isn't either the database's fault nor (usually) the database client library's fault. (“Usually” because there has been the occasional sinner in the past, and we're still fucking stuck with the idiotic mistakes that infest crappy old PHP code like a bad case of the crabs.)

djls45

@blakeyrat said in Saving the World from Code:

YOU'VE JUST LEAKED ALL YOUR EMAILS!

There's also good ways to protect against that, even with SQL injection exposure.

select top 1 accountName, emailAddress
from users
where userId = 34762746327
order by userId;

!!! INJECT 0 OR 1 = 1!!!

select top 1 accountName, emailAddress
from users
where userId = 0 OR 1 = 1
order by userId;

OH NOES! WE JUST EXPOSED A DUMMY ACCOUNT! (requires such honeypot account(s) to exist)

Alternately:
!!! INJECT 0 OR 1 = 1 order by 1!!!

select top 1 accountName, emailAddress
from users
where userId = 0 OR 1 = 1 order by 1
order by userId;

Msg 156, Level 15, State 1, Line 4
Incorrect syntax near the keyword 'order'.

blakeyrat

@djls45 said in Saving the World from Code:

There's also good ways to protect against that, even with SQL injection exposure.

Maybe; but I don't trust the average developer to do it.

japonicus

@djls45 said in Saving the World from Code:

There's also ~~good~~utterly fragile ways to protect against that, even with SQL injection exposure.

!!! INJECT 0 OR username = 'mytargetvictim'!!!

select top 1 accountName, emailAddress
from users
where userId = 0 OR username = 'mytargetvictim'
order by userId;

djls45

@japonicus That implies the attacker knows the relevant column name for the database, which should not be accessible except by someone who already has database access, which means the SQL injection is pointless: they can just access the information directly.

japonicus

@djls45 said in Saving the World from Code:

@japonicus That implies the attacker knows the relevant column name for the database, which should not be accessible except by someone who already has database access, which means the SQL injection is pointless: they can just access the information directly.

But if I'm a diligent hacker then I can keep picking away until I get at all the details needed.

I don't need the complete user list in one fell swoop if I can get the personal details of an admin user then do some spear fishing.

If there's one open injection vulnerability there's almost bound to be others and the system's also likely to be leaking nice juicy error messages to help me with my probing.

Scarlet_Manuka

@kian said in Saving the World from Code:

These two paragraphs struck me because the guy correctly diagnosed the problem, then completely failed on the solution. "Because requirements are ambiguous, let's make a tool that requires perfectly defined requirements."

I think that's a little harsh. I think the intention is more along the lines of "Because requirements are ambiguous, let's make a tool that allows business users to express requirements in a reasonably natural way that still contains much more rigour than a traditional requirements document." (Whether the execution lives up to the intention, of course, is another matter.) A presentation method that, for instance, makes missing edge cases clear and is still natural enough for business users to use directly would be an immense boon for most of us. The part in italics is, of course, what makes it difficult to do.

For example, every year when the sales performance bonus structure changes, and I eventually get the details a few weeks after the start of the year so that I only have a week or so to have them implemented before the first monthly bonuses are due to be calculated, the first step is inevitably to send back a raft of clarifying questions. Generally it's a case of "we didn't think about that possibility, here's an answer I basically made up on the spot." Having a tool that shows these cases as unresolved and forces the business users to think about them ahead of time, before it ever gets down to me, would be great.

Kian

@scarlet_manuka It's a matter of generality vs specificity. A tool that could process requirements and identify "edge cases" would require a certain amount of domain knowledge. The more comprehensive it is, the more limited the domain it can apply to. It might be worth it, but you'll need a programmer to make it, maintain it and extend it, deal with the mistakes that happen when it's misused, etc. And still need someone to turn the enhanced requirements to actual code.

The article wants something that replaces the programming part itself, a way to turn requirements into code. But the problem is not in turning the requirements into code, it's defining the requirements. What you suggest would be nice, and I'd support any efforts to improve requirements gathering, but it's not the kind of transformation the article is talking about.

Scarlet_Manuka

@kian Yes, such a tool would need to be programmed using domain knowledge, and the article acknowledges this (that's the point of the line about how software developers should be trying to make software developers obsolete). The idea is that developers shouldn't be writing implementation code, they should be writing requirements modelling code; since turning precise requirements into code is the easy part, that can be baked right into the tool so that once the requirements are correct, the corresponding code can be directly generated. What I wrote about is a partial step towards this goal, a requirements modelling tool that at least encourages a more precise specification than what we have now.

Where I think the idea falls down - well, there are a number of places:

If this took off in a big way, we'd get lots of really buggy requirements models, in the same way that we get lots of buggy code now, and with the same end result.
Only really provides a benefit in cases where you'll have several projects go through in the same domain - if there's only one, you need to go through the entire requirements elucidation process to build the tool properly in the first place, and once you've done that you may as well just implement the elucidated requirements.
The key to this is giving a good UI to the business users to define their requirements. Who's going to make that UI? Probably a programmer who has no idea about UI design.
Because each domain will have different needs, it seems like it would be hard to build frameworks for this type of stuff to help out.

Ultimately I don't think we're as far off in our readings of it as you seem to think. It's a good idea as far as it goes and it may see some traction in some domains where someone can create a really good requirements tool and lots of different places can use it, but it's not a panacea for the overall problem (shocker). I do insist that anything which leads to the business users being able to generate more precise requirements, whether this approach or another, is a good thing.

Dreikin

@djls45 said in Saving the World from Code:

@japonicus That implies the attacker knows the relevant column name for the database, which should not be accessible except by someone who already has database access, which means the SQL injection is pointless: they can just access the information directly.

Lots of potentially vulnerable software is open source. Does WordPress use custom user account columns per install or something?

Also, a lot of the basic columns are probably just as predictable, if not more, than passwords.

Dreikin

@scarlet_manuka said in Saving the World from Code:

makes missing edge cases clear

This is what occasionally makes me sympathetic to Java's idea of requiring each method to be explicit about what it can throw (or what can be thrown up from under it). Makes sure those edge cases are presented, even if they're not given much attention.

magnusmaster

@blakeyrat The only safe compiled language that has some use today is Rust, and it allows you to write unsafe code for a reason (and it's not just talking to C code).

Dreikin

@scarlet_manuka said in Saving the World from Code:

@kian Yes, such a tool would need to be programmed using domain knowledge, and the article acknowledges this (that's the point of the line about how software developers should be trying to make software developers obsolete). The idea is that developers shouldn't be writing implementation code, they should be writing requirements modelling code; since turning precise requirements into code is the easy part, that can be baked right into the tool so that once the requirements are correct, the corresponding code can be directly generated. What I wrote about is a partial step towards this goal, a requirements modelling tool that at least encourages a more precise specification than what we have now.

Where I think the idea falls down - well, there are a number of places:

If this took off in a big way, we'd get lots of really buggy requirements models, in the same way that we get lots of buggy code now, and with the same end result.

Only really provides a benefit in cases where you'll have several projects go through in the same domain - if there's only one, you need to go through the entire requirements elucidation process to build the tool properly in the first place, and once you've done that you may as well just implement the elucidated requirements.

The key to this is giving a good UI to the business users to define their requirements. Who's going to make that UI? Probably a programmer who has no idea about UI design.

Because each domain will have different needs, it seems like it would be hard to build frameworks for this type of stuff to help out.

Ultimately I don't think we're as far off in our readings of it as you seem to think. It's a good idea as far as it goes and it may see some traction in some domains where someone can create a really good requirements tool and lots of different places can use it, but it's not a panacea for the overall problem (shocker). I do insist that anything which leads to the business users being able to generate more precise requirements, whether this approach or another, is a good thing.

This seems doable, actually, and generically too. Well, the gist of it anyway.

Imagine if you will, a tool for business users to plot out requirements, and for developers to in turn ask for clarification on those requirements. The tool could host many different things, from basic ideas and sketches, to flowcharts, GUI skeletons, and image assets. Let's imagine a piece of the work underway.

An executive, let's call him Tom, has created a flowchart documenting how this year's bonuses are to be calculated. It's fairly basic, composed of filter blocks ("only applies to executives") and branches ("if executive is C-level"). Tom, thinking it complete, hits "Submit" which in turn notifies the relevant lead/sole developer of the project that a new requirement document has been added. The developer, Dick, notices a few things are incompletely specified, and flushes out the diagram with proposal blocks and question blocks, as well as re-ordering a few parts of the flow diagram related to them. The developer then hits their submit button, sending it back to the original editor, Tom, for review. Tom clicks a link and sees the diagram with all the developer's additions and changes highlighted. Proposal blocks have approve/deny/rework checkboxes, as well as a notes area. The question blocks are meant to be replaced by whatever Tom thinks is good.

Back and forth they go, iteratively updating the flowchart until finally there is nothing more either of them thinks needs added or clarified. Tom approves it, Dick approves it, and Dick then tells his junior, Harry, to implement it (who, in turn, can send his own proposals and questions upstream).

This does seem like an idea for a good tool usable by every Tom, Dick, and Harry out there.

blakeyrat

@magnusmaster Is the "that has some use today" weasel-wording specifically design to disqualify Go? Because Go is like 20 times more popular than Rust, so.

ScholRLEA

Resig is a celebrated programmer of JavaScript—software he wrote powers over half of all websites—

True; he was the original dev of JQuery, and t least officially, still the lead on the project. However, in this context this is misleading, as JQuery is definitely not particularly 'visual', and if anything is steep deeply in the code-oriented processes the article is decrying. I don't know what he's worked on lately, though, and even if he isn't working in visual and other alternative methods of development, he does have the background to make a sensible comment on the topic.

So, what's he up to lately?

and a tech lead at the online-education site Khan Academy.

Wow, my respect for him just plummeted. My impression is that Khan's courses are pretty good at getting people's feet wet, but they do so in ways that, not to be too harsh, tend to make it harder to take further steps - they sound like the online spiritual successor to the Learn x in y Days type of textbooks, and enshrine the Sewage Overflow approach to 'programming' in a way that is sure to haunt the industry for generations. I may be wrong, however - any comments or corrections here?

ScholRLEA

But seeing the impact that his talk ended up having, Bret Victor was disillusioned. “A lot of those things seemed like misinterpretations of what I was saying,” he said later.

I think this article just added to that. Why? Because he mostly works in data modeling. He is not focusing on general programming at all - he's concerned with how we work with things like visual representations of, say, statistical data, and doing what-if analyses through drag-and-drop, constraints, things like that - basically, combining Bricklin spreadsheet model and Sutherland's visual constraints to how we show display databases and data projections.

He's not say 'code is bad', but rather that writing this sort of thing directly in code the wrong way to do them - which shouldn't be controversial, but... apparently is?

He does talk about how rigid the ways code is written can be, and I think he is spot on with that. He compares how Smalltalk's class browser represents the code to how, say, VS or Eclipse does, and points out that the mainstream approaches are visually shallow compared to the 40-year-old Smalltalk approach - and points out that, while it would not be easy given the continued use of strictly linear, file-oriented code modules, there's no real reason that Java or C# code couldn't be shown in a more visually compelling manner, rather than having the editor exactly mirror the source file as nearly every editor today still does. He also mentions that we still manually code a lot of crap that could be done through constraints, or by self-adjusting protocols. But in both of those cases what he's really saying is that we're hamstringing the ways we are creating the code, despite having better ways to do it that would allow us to focus on making new code rather than endlessly re-writing things the same ways.

ScholRLEA

Just to give some context to the stuff regarding Bret Victor, here's the lecture the article is primarily talking about, "Inventing On Principle":

https://youtu.be/PUv66718DII

And one we've discussed at length here before, "The Future of Programming (1973)", as part of a playlist of several of his talks:

https://www.youtube.com/watch?v=8pTEmbeENF4&list=PLjhH01A4YOO3h0LwGNTf2F37L0_Gn7O4D

djls45

@Dreikin How do you define the requirements for that tool?

Dreikin

@djls45 said in Saving the World from Code:

@Dreikin How do you define the requirements for that tool?

Recursively, of course.

Dreikin

@djls45 said in Saving the World from Code:

@Dreikin How do you define the requirements for that tool?

More seriously, do you mean what do I think the requirements spec for it should be, or the manner in which they're defined? If the former, it's just an idea at the moment. If the latter, by whichever manner works currently.

djls45

@dreikin Moreso the former, but answers to both would be good, too.

I can kinda see something that -- building a program from the top down by writing an overall logic flow, then maybe "zooming in" on a block to more specifically define the flow for particular pieces, and being able to "zoom in" again on a sub-section, and so on, down to the point where "regular" code exists. Two issues I see with it, though, are that being able to reuse the same piece of code might be harder to implement and that it would require a very high level of modularization and abstraction to construct the program. I guess in a way, though, it's just visualizing the existing classes and code structure.

Dreikin

@djls45 said in Saving the World from Code:

@dreikin Moreso the former, but answers to both would be good, too.

I can kinda see something that -- building a program from the top down by writing an overall logic flow, then maybe "zooming in" on a block to more specifically define the flow for particular pieces, and being able to "zoom in" again on a sub-section, and so on, down to the point where "regular" code exists. Two issues I see with it, though, are that being able to reuse the same piece of code might be harder to implement and that it would require a very high level of modularization and abstraction to construct the program. I guess in a way, though, it's just visualizing the existing classes and code structure.

Ah, I gotcha. I was actually not integrating the coding, but talking about a better tool for dealing with requirements gathering and workflow (the programmer still does the conversion from reqs to code). More like a step to the proposed final destination than a leap next to it.

dkf

@magnusmaster said in Saving the World from Code:

The only safe compiled language that has some use today is Rust

No. That's provably wrong as there are people who are using Haskell.

cvi

@dkf said in Saving the World from Code:

No. That's provably wrong as there are people who are using Haskell.

Or Erlang.

Besides, just using Rust (or any of these languages) is only solving a bit of the problem anyway. For example, there are chips+code that needs to be able to continue to function even if memory (and other state) is corrupted by external factors. Testing this involves injecting faults (flipping random bits) directly in the hardware. None of the current crop of languages help you there.

ScholRLEA

@boomzilla said in Saving the World from Code:

You could just have sane clients like I do and it won't be a problem.

Show of hands, who here has ever had one sane client/primary stakeholder? I sure as fuck haven't.

Dreikin

@scholrlea said in Saving the World from Code:

@boomzilla said in Saving the World from Code:

You could just have sane clients like I do and it won't be a problem.

Show of hands, who here has ever had one sane client/primary stakeholder? I sure as fuck haven't.

dkf

@scholrlea said in Saving the World from Code:

Show of hands, who here has ever had one sane client/primary stakeholder?

Just to throw in a curve-ball, there's good insane as well as bad insane.