Really folks?
-
@blakeyrat said:
@anotherusername said:
That is the perfect recipe for someone who knows just enough to be dangerous in every possible situation. Also known as a fool; someone who doesn't know what he doesn't know until after he's screwed things up sufficiently that even he, with his overinflated sense of his own capabilities, can't find any way to fix his cockup.Hmm, now tell me how you feel about the makers of the Pi not selling a kit so you could try to bake its package-on-package RAM with a 0.5mm pitch. Because if you can't do it yourself, it's obviously a usability problem, right?
Right.
-
@anotherusername said:
That is the perfect recipe for someone who knows just enough to be dangerous in every possible situation. Also known as a fool; someone who doesn't know what he doesn't know until after he's screwed things up sufficiently that even he, with his overinflated sense of his own capabilities, can't find any way to fix his cockup.
Then it's not usable enough.
-
@blakeyrat said:
@anotherusername said:
No, you're not usable enough. Unsafe for any job duties unless you're given some fabled tool that does everything for you and requires absolutely no preknowledge or expertise. Congratulations, you're redundant. Anyone can blame his tools for his inability to get shit done.That is the perfect recipe for someone who knows just enough to be dangerous in every possible situation. Also known as a fool; someone who doesn't know what he doesn't know until after he's screwed things up sufficiently that even he, with his overinflated sense of his own capabilities, can't find any way to fix his cockup.
Then it's not usable enough.
-
@anonymous234 said:
@Snooder said:
What if we made some kind of lightweight database? Like an application where you could enter values, and program relationships between values in simple formulas, and maybe save everything in a single file for practicality... it would be good for simple computations.
See, a large part of what makes a database actually useful are the things that make it complicated. If you strip out the complexity, you also strip out the usefulness. Which is why such people should simply leave it to people who actually know what they are doing.Perhaps some kind of 2D grid...
That's not a database. That's a table. There is a difference. Hell, I'm no database guru but I remember at least that much from my college classes.See, the point of a database is not to store things in a column/row format. The point of a database is to store information in a form that can be queried. Excel is really good at storing tables. It is not meant for, and should be not be used heavily for quering data.
@blakeyrat said:@Snooder said:
The problem is not "people can't figure out how to use an actual database" it's "people who have no business using a database don't have the training to understand what a database is or does."
If they've build an Excel app that you think should be moved into a
database, then demonstrably they do have business using a
database.@Snooder said:
See, a large part of what makes a database
actually useful are the things that make it complicated.Bullshit.
@Snooder said:
If you strip out the complexity, you also strip
out the usefulness.Double-bullshit.
@Snooder said:
Which is why such people should simply leave it to
people who actually know what they are doing.Mega-ultra-super-bullshit.
There is a difference between someone having a business need to use a
database and someone who has the skill to use a database. I was
referring to the latter.
See above re: the purpose of a database. See, the problem does not exist when someone who does not have the proper training to understand how to query and analyze data builds an excel spreadsheet to simply store some data. Great, it's doing what it's meant to do.The problem happens when that same person tries to use excel to then manage that data. This is a complex thing that actually requires a great deal of training to handle correctly. Excel is a simple tool, so the person decides that instead of either getting the training he needs, or getting someone with that training, he'll use a simple tool for a complex job. And then we have a clusterfuck.
-
You have the problem, but you don't have the solution.
The solution is for database software to be made as, or more, usable than Excel. Not for the user to "go find an expert" or "get the training he needs". Guess what? If the database program didn't suck shit in the first place, maybe he wouldn't need training at all.
-
@blakeyrat said:
You have the problem, but you don't have the solution.
What you describe has been done, and it is called Access. Complete idiots can put together an ill-designed database that works poorly. And in your attempt to make a product that doesn't suck shit, you inevitably result with the user creating something that does suck shit because he's just empowered enough to fuck things up.The solution is for database software to be made as, or more, usable than Excel. Not for the user to "go find an expert" or "get the training he needs". Guess what? If the database program didn't suck shit in the first place, maybe he wouldn't need training at all.
-
One product tried it and didn't do so great, therefore the entire concept of usability is broken. Since it's impossible for other teams to maybe try different things, the entire industry is done and we might as well all just give up.
Congratulations, you've solved everything.
-
Funnily enough, I saw a working example of this literally today (unless it's now tomorrow).
1) Clients use Excel to prep data for a data import
2) Some text data needs to be transformed, because the import target can't handle the raw data
3) We have a DLL that can do the transform, but since the import is 3rd party, we can't inject it between data import and write to database.
4) DLL can be added to an Excel as a User Defined Function, but it isn't feasible to require clients to do this.
5) Developer added the DLL into, let's call it, "FunctionSpreadSheet.xls" Excel as a User Defined Function
6) Give "FunctionSpreadSheet" the spreadsheet to the clients, along with instructions
7) Clients now open "FunctionSpreadSheet.xls" and their data import spreadsheet. They copy a formula with value ="FunctionSpreadSheet.xls"!Transform(A1) , change A1 as needed, and drag-expand-copy it
Data is now properly transformed before input. Client cannot have more than one copy of FunctionSpreadSheet.xls open.
I'm not saying the above is an argument FOR or AGAINST how it works. But it works.
-
@blakeyrat said:
The solution is for database software to be made as, or more, usable than Excel.
That only needs to be true in regards to the target audience/market.Consider the case of mobile phone apps. They're often little more than a little wrapper round a database or two (e.g., an embedded database for local state and a remote database powering a website). Does anyone deliver such things in that area on top of Excel? No. Those databases must therefore be more usable than Excel for what they are doing.
There are also a lot of areas where correctness is more important than usability, and the ultimate metric is “can we make a profit by selling these after allowing for any lawsuits?”.
-
@Zylon said:
The problem with Excel is that apparently, at the very core of its being, it was created with the notion that nobody would ever, EVER want to look at two unrelated spreadsheets at the same time. Hence why it can't manage the seemingly trivial task of having multiple windows active at the same time. Open two Excel documents? Sure, it'll happily show two buttons on the taskbar, but then you realize they're both being shared by a single fucking window. Argh.
Granted, with some hackery it's possible to make Excel run a new instance of itself for every document so you can accomplish black magic like comparing two spreadsheets on multiple monitors, but it breaks some common tasks in the process.
They fixed this (finally) in Excel 2013. It was a big suprise to me, but Excel is finally usable with multiple monitors now.
-
@blakeyrat said:
You have the problem, but you don't have the solution.
The solution is for database software to be made as, or more, usable than Excel. Not for the user to "go find an expert" or "get the training he needs". Guess what? If the database program didn't suck shit in the first place, maybe he wouldn't need training at all.
The problem, as I said earlier, is that a lot of the things that make databases difficult to understand are REQUIRED for them to be useful for professional use. You know how sql has all these arcane rules about transaction processing, what commits go when, and requires you to learn a whole language just to insert and find stuff in the database? There's a reason for that. Designing and using a system for collating data requires knowing how to do that stuff. This is not a trivial thing that someone without training can do. If you remove the ability to do that stuff so that someone without training isn't confused, then you remove the ability of a professional to actually do useful things with the database.
Frankly, the only reason it wouldn't be a solution is when people are too cheap to get someone else, too lazy to learn, or too full of their own egos to accept that there might actually be things that they do not know. And none of those are good reasons.
-
@Lorne Kates said:
Funnily enough, I saw a working example of this literally today (unless it's now tomorrow).
1) Clients use Excel to prep data for a data import
2) Some text data needs to be transformed, because the import target can't handle the raw data
3) We have a DLL that can do the transform, but since the import is 3rd party, we can't inject it between data import and write to database.
4) DLL can be added to an Excel as a User Defined Function, but it isn't feasible to require clients to do this.
5) Developer added the DLL into, let's call it, "FunctionSpreadSheet.xls" Excel as a User Defined Function
6) Give "FunctionSpreadSheet" the spreadsheet to the clients, along with instructions
7) Clients now open "FunctionSpreadSheet.xls" and their data import spreadsheet. They copy a formula with value ="FunctionSpreadSheet.xls"!Transform(A1) , change A1 as needed, and drag-expand-copy it
Data is now properly transformed before input. Client cannot have more than one copy of FunctionSpreadSheet.xls open.
I'm not saying the above is an argument FOR or AGAINST how it works. But it works.
Why not just have an exe that when run in the same folder as the data import spreadsheet, parses it, transforms the data and spits out a new spreadsheet?
-
@Snooder said:
The problem, as I said earlier, is that a lot of the things that make databases difficult to understand are REQUIRED for them to be useful for professional use.
I disagree with you.
@Snooder said:
You know how sql has all these arcane rules about transaction processing, what commits go when, and requires you to learn a whole language just to insert and find stuff in the database? There's a reason for that.
There's no law that says the software can't teach you how to use it correctly as you go. Video games for example have made an industry out of exactly that.
As far as programming languages go, SQL's actually pretty easy to learn. (At least for people who have never touched procedural programming.) And of course, there's no law that says a DBMS has to use SQL. Mongo doesn't, and seems to be pretty damned popular.
@Snooder said:
If you remove the ability to do that stuff so that someone without training isn't confused, then you remove the ability of a professional to actually do useful things with the database.
Nobody said anything about removing anything. Except you. Why do you assume making a DBMS usable would involve removing (useful) features?
@Snooder said:
Frankly, the only reason it wouldn't be a solution is when people are too cheap to get someone else, too lazy to learn, or too full of their own egos to accept that there might actually be things that they do not know. And none of those are good reasons.
I'm not sure what "it" refers to in this sentence.
Let's lay it out on the table: what you're really talking about is job protectionism. You're the weaver, my idea is the waterwheel-powered loom, and that post is a wooden shoe thrown into the gears. Fucking admit it. That's all you care about.
-
@blakeyrat said:
@Snooder said:
You know how sql has all these arcane rules about transaction processing, what commits go when, and requires you to learn a whole language just to insert and find stuff in the database? There's a reason for that.
There's no law that says the software can't teach you how to use it correctly as you go.Of course it can. However when doing the teaching it needs to be done carefully, or it becomes more damaging than beneficial.
@blakeyrat said:
@Snooder said:
Frankly, the only reason it wouldn't be a solution is when people are too cheap to get someone else, too lazy to learn, or too full of their own egos to accept that there might actually be things that they do not know. And none of those are good reasons.
I'm not sure what "it" refers to in this sentence.Let's lay it out on the table: what you're really talking about is job protectionism. You're the weaver, my idea is the waterwheel-powered loom, and that post is a wooden shoe thrown into the gears. Fucking admit it. That's all you care about.
It certainly sounds like he is arguing for protectionism, but only if you ignore an issue about making the software teach. It is expensive to make a complicated system teach itself to a user. There are limited amounts of time and resources for making software. Thus it can make economic sense to not make something the idealised super usable wonder product that you want and instead build the training required product that Snooder is arguing for (it's just that he says "can't" but should be saying "not worth the cost").
-
@blakeyrat said:
Let's lay it out on the table: what you're really talking about is job protectionism. You're the weaver, my idea is the waterwheel-powered loom, and that post is a wooden shoe thrown into the gears. Fucking admit it. That's all you care about.
A DBMS is meant as a general purpose but relatively low level tool. It's like saying that people should all be able to use a compiler to just build their applications, rather than relying on specialists to do this for them. I know you'll just say you're being idealist, but really you're just trying to immanentize the computing eschaton. It's just not going to happen, and trying to get there in the way you're suggesting is counter-productive, because you're requiring not just a better piece of software but a better humanity.
-
@Snooder said:
@blakeyrat said:
You have the problem, but you don't have the solution.
The solution is for database software to be made as, or more, usable than Excel. Not for the user to "go find an expert" or "get the training he needs". Guess what? If the database program didn't suck shit in the first place, maybe he wouldn't need training at all.
The problem, as I said earlier, is that a lot of the things that make databases difficult to understand are REQUIRED for them to be useful for professional use. You know how sql has all these arcane rules about transaction processing, what commits go when, and requires you to learn a whole language just to insert and find stuff in the database? There's a reason for that. Designing and using a system for collating data requires knowing how to do that stuff. This is not a trivial thing that someone without training can do. If you remove the ability to do that stuff so that someone without training isn't confused, then you remove the ability of a professional to actually do useful things with the database.
Frankly, the only reason it wouldn't be a solution is when people are too cheap to get someone else, too lazy to learn, or too full of their own egos to accept that there might actually be things that they do not know. And none of those are good reasons.The address book on my phone is a database, presumably has the full complement of transactional logic and integrity, and requires no arcane languages or special knowledge to use.
The point isn't "lock anyone who doesn't meet an arbitrary knowledge standard out", it's "remove the chaff from the database system so that it can serve one purpose well".
It's the difference between a good purpose-built system and a general-purpose one. SQL Server is a good general purpose RDBMS, but a terrible tool for any one task. "I set up a SQL Server instance to keep my notes in!" is an insane statement, regardless of the knowledge of the person making that claim.
Usability often means keeping the scope of a system appropriately limited so that a user doesn't do the wrong thing more easily than the right one (see: PHP for an example of this being massively fucked)
As a programmer, I'm sure you're capable of writing a new database engine from scratch for every project, but you probably don't. You probably write a unique schema for a known RDBMS instead, or maybe use some object-relational framework or tool. In this case, you're choosing a more usable tool (SQL), instead of a more powerful one (C/++ or Java or such). There are almost certainly people out there who would chastise you for doing this, since it means the project ends up with exterior dependencies, has heftier hardware requirements, etc, but they are just as wrong as the person claiming that "tools should be strange and difficult to use in order to prevent mistakes". No, tools should be written such that the easy way = the correct way, and fucking things up requires doing something insane.
-
@locallunatic said:
It certainly sounds like he is arguing for protectionism, but only if you ignore an issue about making the software teach. It is expensive to make a complicated system teach itself to a user.
I won't argue that, but at least it only has to be done once. I also think there's a ethical component here that transcends, to some extent, the cost in dollars.
@locallunatic said:
Thus it can make economic sense to not make something the idealised super usable wonder product that you want and instead build the training required product that Snooder is arguing for (it's just that he says "can't" but should be saying "not worth the cost").
... but once you've made it, you can sell it to millions more people. So I would argue it is worth the development cost, but of course I haven't run numbers. And neither has Snooder.
But I've also used HyperCard.
-
@Buttembly Coder said:
The address book on my phone is a database, presumably has the full complement of transactional logic and integrity, and requires no arcane languages or special knowledge to use.
As I said earlier, I'm not talking about that sort of use. Yes, you can use your address book to store phone numbes. What you can't do with it is create a custom database to (just as an example) correllate phone numbers with sexual proclivities, ratings on Hot-Or-Not, picture and physical proxmity, then create a query to pull up the best available booty call. It's this latter sort of use that I'm saying Excel is bad at doing, and which quite frankly people who can only use Excel shouldn't be doing.
You don't need to know how to create and manage a database to use your address book. The guy who *wrote* your address book software on the other hand, damn well better know how to do that.@Buttembly Coder said:
The point isn't "lock anyone who doesn't meet an arbitrary knowledge standard out", it's "remove the chaff from the database system so that it can serve one purpose well".
And I'm saying that once you have a database system that only "serve[s] one purpose well" you no longer have a database system that's useful for the sort of professional use I'm referring to. Which is the sort of professional use that people try to use Excel to do. And is the sort of professional use that requires knowledge.
-
@Snooder said:
@Buttembly Coder said:
The address book on my phone is a database, presumably has the full complement of transactional logic and integrity, and requires no arcane languages or special knowledge to use.
As I said earlier, I'm not talking about that sort of use. Yes, you can use your address book to store phone numbes. What you can't do with it is create a custom database to (just as an example) correllate phone numbers with sexual proclivities, ratings on Hot-Or-Not, picture and physical proxmity, then create a query to pull up the best available booty call. It's this latter sort of use that I'm saying Excel is bad at doing, and which quite frankly people who can only use Excel shouldn't be doing.
You don't need to know how to create and manage a database to use your address book. The guy who wrote your address book software on the other hand, damn well better know how to do that.@Buttembly Coder said:
The point isn't "lock anyone who doesn't meet an arbitrary knowledge standard out", it's "remove the chaff from the database system so that it can serve one purpose well".
And I'm saying that once you have a database system that only "serve[s] one purpose well" you no longer have a database system that's useful for the sort of professional use I'm referring to. Which is the sort of professional use that people try to use Excel to do. And is the sort of professional use that requires knowledge.This is actually the point I'm trying to make: usability - can it be used, I guess you could contrast this with programmability? Essentially, the tools for most every purpose someone would need a database should already exist, and be polished and usable.
-
@blakeyrat said:
Let's lay it out on the table: what you're really talking about is job protectionism. You're the weaver, my idea is the waterwheel-powered loom, and that post is a wooden shoe thrown into the gears. Fucking admit it. That's all you care about.
As I said earlier, I'm not a DBA. I'm not an expert in databases. I am however both smart enough and realistic enough to accept that there are things about databases that I don't know or care to know. I know enough to facillitate most of my programming work, and when it run into something more complex, I refer it to someone more knowledgeable. When I see someone without even the minimal knowledge that I have trying to build a database system with fucking excel just because that's all they know how to do, it boggles the mind.
You seem to be advocating that the software itself replace months or even years of training though an extended tutorial sequence. That's ok, I guess, but why design the software to do that, when someone who is being paid to do this work should already get that training himself? And how likely are you to get people who are actually trained out of the process? Rather than the equivalent of the guy in the Holiday Inn commercials who stays one night and thinks he's an expert in everything.
-
@Buttembly Coder said:
This is actually the point I'm trying to make: usability - can it be used, I guess you could contrast this with programmability? Essentially, the tools for most every purpose someone would need a database should already exist, and be polished and usable.
Ok then. I've been referring to "usability" from the point of view of someone writing software, like the sort of custom one-off line of business applications that we tend to see ugly excel implementations in. I guess we could start referring to it as "programmability."
What you are suggesting is impossible. It's physically impossible for a ready made database system to exist for every purpose. Because every second of every day, someone out there is coming up with a new and unique use-case that requires a custom solution. It's just not possible to concieve of every purpose ahead of time.
Like my suggestion of a little black book for the modern Lothario. Yeah, you can probably think that one up really easily. But what if the guy using it lives in Alaska and only hooks up with people in Second Life or something. The application (and the underlying database) would need to be rewritten to use whatever bullshit people in Second Life instead of real addresses. Or maybe someone is more concerned with making sure that everyone he sleeps with is STD free. Again, needs to be rewritten to accommodate health record data. There are an infinite variety and it's not possible to ever say "yes, NOW we have every contingency covered." Unless you make the application more open and rely on the users doing personal customizations themselves, which leads to it becomes a shitty version of a general purpose database system... I think you see where that's going.
-
@Snooder said:
@Buttembly Coder said:
This is actually the point I'm trying to make: usability - can it be used, I guess you could contrast this with programmability? Essentially, the tools for most every purpose someone would need a database should already exist, and be polished and usable.
Ok then. I've been referring to "usability" from the point of view of someone writing software, like the sort of custom one-off line of business applications that we tend to see ugly excel implementations in. I guess we could start referring to it as "programmability."
What you are suggesting is impossible. It's physically impossible for a ready made database system to exist for every purpose. Because every second of every day, someone out there is coming up with a new and unique use-case that requires a custom solution. It's just not possible to concieve of every purpose ahead of time.
Like my suggestion of a little black book for the modern Lothario. Yeah, you can probably think that one up really easily. But what if the guy using it lives in Alaska and only hooks up with people in Second Life or something. The application (and the underlying database) would need to be rewritten to use whatever bullshit people in Second Life instead of real addresses. Or maybe someone is more concerned with making sure that everyone he sleeps with is STD free. Again, needs to be rewritten to accommodate health record data. There are an infinite variety and it's not possible to ever say "yes, NOW we have every contingency covered." Unless you make the application more open and rely on the users doing personal customizations themselves, which leads to it becomes a shitty version of a general purpose database system... I think you see where that's going.I think you're trying to apply my "most every" to a theoretical "every". Obviously there are asinine corner-cases where someone has a truly novel need for a system, but those are almost always so small that the person really could just use excel. A database of business contacts, a database of sales records, an invoicing system, etc, etc, etc,.. These all already exist, and in most cases would be the proper tools. Most of them are fucking terrible, and usually hideously expensive for what they do. In the examples you provide, there's really nothing more complicated in need than an "add a field: name/value" button on the "add a person" form.
-
@Buttembly Coder said:
A database of business contacts, a database of sales records, an invoicing system, etc, etc, etc,.. These all already exist, and in most cases would be the proper tools. Most of them are fucking terrible, and usually hideously expensive for what they do. In the examples you provide, there's really nothing more complicated in need than an "add a field: name/value" button on the "add a person" form
Sure, but to get back on the topic of ridiculing the ideas of stupid people, did / should the business users have already created those programs or is it OK to have a profession of people dedicated to that sort of thing? Until there's godlike artificial intelligence, there's a ton of value in specialization and division of labor in developing computer programs / automation.
-
@boomzilla said:
@Buttembly Coder said:
A database of business contacts, a database of sales records, an invoicing system, etc, etc, etc,.. These all already exist, and in most cases would be the proper tools. Most of them are fucking terrible, and usually hideously expensive for what they do. In the examples you provide, there's really nothing more complicated in need than an "add a field: name/value" button on the "add a person" form
Sure, but to get back on the topic of ridiculing the ideas of stupid people, did / should the business users have already created those programs or is it OK to have a profession of people dedicated to that sort of thing? Until there's godlike artificial intelligence, there's a ton of value in specialization and division of labor in developing computer programs / automation.
Programmers have had at least 50 years to make good software, and I think all we've proven is that we suck at our jobs.
-
@Buttembly Coder said:
I think you're trying to apply my "most every" to a theoretical "every". Obviously there are asinine corner-cases where someone has a truly novel need for a system, but those are almost always so small that the person really could just use excel. A database of business contacts, a database of sales records, an invoicing system, etc, etc, etc,.. These all already exist, and in most cases would be the proper tools. Most of them are fucking terrible, and usually hideously expensive for what they do. In the examples you provide, there's really nothing more complicated in need than an "add a field: name/value" button on the "add a person" form.
Really? Without even looking into the format of the data we're talking about, you jump right to "add a new field" Hell, you don't even know what form the underlying data structure is. I can fucking guarantee you that integrating health record data in any useful form would take a great deal more than just "add a new field." I mean, how would you include say 12 years of sexually active medical records for a 30 year old into a single field? Let's say you instead have a ton of new fields. What happens when you have Kareem Abdul Jabbar using the app and he has a couple thousand entries each with 10 or more years worth of medical visits and tests? What if you only have a few people in your black book, but one of them happens to be Sasha Grey? Dealing with things like that is important, and is the sort of thing that professionals at building databases are taught to do. And for which they need appropriate tools to let them handle doing.
-
@Snooder said:
Why not just have an exe that when run in the same folder as the data import spreadsheet, parses it, transforms the data and spits out a new spreadsheet?
If all they're doing is manipulating data, I find it really hard to believe that it can't be done using formulas in Excel, or at least in VBA without requiring a plugin to be installed. Excel plugins are a PITA (I've used them); I suspect Microsoft wanted to strongly encourage developers to build frameworks for Excel's built-in data import tool to connect to rather than using plugins.
-
@Snooder said:
I know enough to facillitate most of my programming work, and when it run into something more complex, I refer it to someone more knowledgeable.
You would be surprised to learn:
1) How (relatively) easy DBMSes are to use (MS SQL Server being the best, but the others aren't really too far behind), and
2) How much full of shit most full-time DBAs are.Or, if you're fond of thinking of me as an idiot, put it this way: "if Blakeyrat can figure out replication in SQL Server, anybody can."
Most DBAs make things look harder than they really are because, back in 1988 when the job position started, things *were* hard. And because they're trying to save their own salaries. In reality, most of them now either spend all their time doing endless change request paperwork, or pointlessly tweaking with the DBMS and doing as much harm as good. Most. Not all.
@Snooder said:
You seem to be advocating that the software itself replace months or even years of training though an extended tutorial sequence. That's ok, I guess, but why design the software to do that, when someone who is being paid to do this work should already get that training himself?
Because if the software does that, you've empowered millions of people to accomplish a task they wouldn't have been able to otherwise. That's what computers are all about. That's why they're here. That's the stuff you're supposed to get excited about.
@Snooder said:
And how likely are you to get people who are actually trained out of the process?
The training is secondary to, "did they accomplish the task they set out to do?" Whether what this theoretical application told them during the process is useful for another task isn't important; what is it that it's important for accomplishing the task they set out to accomplish when they opened the program.
-
@Buttembly Coder said:
Programmers have had at least 50 years to make good software, and I think all we've proven is that we suck at our jobs.
Right! Hell, receptionist Dave at the front desk might turn out to be a brilliant application designer if we could only give him the tools he needs in a form he understands!
-
@blakeyrat said:
@Buttembly Coder said:
Programmers have had at least 50 years to make good software, and I think all we've proven is that we suck at our jobs.
Right! Hell, receptionist Dave at the front desk might turn out to be a brilliant application designer if we could only give him the tools he needs in a form he understands!I don't really disagree with Buttembly Coder, but I'm not going to one step further and say that the solution is to encourage people who can't count to 11 without taking off their shoes to fill in the gap is the solution.
-
@blakeyrat said:
Right! Hell, receptionist Jolene at the front desk might turn out to be a brilliant application designer if we could only give her the tools she needs in a form she understands!
No. She might be able to follow a rather inflexible scripted path written by a brilliant application designer, but the mark of brilliance is understanding the tools better than the average person, and no amount of hand-holding will produce that in someone. A brilliant designer has to be motivated to figure out how things work and exploit them in creative and new ways.
-
@Snooder said:
@Buttembly Coder said:
I think you're trying to apply my "most every" to a theoretical "every". Obviously there are asinine corner-cases where someone has a truly novel need for a system, but those are almost always so small that the person really could just use excel. A database of business contacts, a database of sales records, an invoicing system, etc, etc, etc,.. These all already exist, and in most cases would be the proper tools. Most of them are fucking terrible, and usually hideously expensive for what they do. In the examples you provide, there's really nothing more complicated in need than an "add a field: name/value" button on the "add a person" form.
Really? Without even looking into the format of the data we're talking about, you jump right to "add a new field" Hell, you don't even know what form the underlying data structure is. I can fucking guarantee you that integrating health record data in any useful form would take a great deal more than just "add a new field." I mean, how would you include say 12 years of sexually active medical records for a 30 year old into a single field? Let's say you instead have a ton of new fields. What happens when you have Kareem Abdul Jabbar using the app and he has a couple thousand entries each with 10 or more years worth of medical visits and tests? What if you only have a few people in your black book, but one of them happens to be Sasha Grey? Dealing with things like that is important, and is the sort of thing that professionals at building databases are taught to do. And for which they need appropriate tools to let them handle doing.
Please read my signature, I believe it applies at this point.If you have to resort to ridiculous examples to make your argument, that means your argument is ridiculous.
-
@blakeyrat said:
@Buttembly Coder said:
Programmers have had at least 50 years to make good software, and I think all we've proven is that we suck at our jobs.
Right! Hell, receptionist Dave at the front desk might turn out to be a brilliant application designer if we could only give him the tools he needs in a form he understands!
And that's the bullshit I'm trying to get you to see past.
See, there's a difference between an "application designer" and a "software architect." Dave can have a really good idea, and know exactly what his userbase wants. But if he doesn't have the talent or drive to learn how to write code, he's never going to actually understand it. The best we can do is dumb down the process and abstract away enough things for him to believe that he understands when he's actually clueless.
I know plenty of MBA types who are great "application designers." They are shit coders, and I wouldn't trust them with a compiler in a millions years. More importantly though, they don't need to be good coders. They can get a good coder to do that stuff for them while they focus on the things they are actually good at doing. Sure, if they are also good at writing software, then they can do both, but if they aren't good at writing software, ruining software development tools to cater to them is not the answer.
I've met great software architects. I don't just mean the guy who manages to squeak out some project under a deadline without too many bugs. I mean the guy who can take a system, sit down and understand the underlying processes well enough to identify places that need to be improved. Or can take an idea sit with it for a while and come up with a completly novel and revolutionary approach. The kind of guy who comes up a brand new algorithm that wins Turing awards. I'm not that great. Even on my best day, I'm a pale shadow of that. But that's what I aspire to be, and what every one else in this profession should aspire to. Software tools should be written for and usable for those people. Not for the sort of guy like Dave who doesn't know shit about math, cares fuck all about algorithms, has no idea what a data structure is, doesn't understand recursion, is completely ignorant of locking and multi-threading, and just wants to make the pretty lights move in a specific direction. That guy should write his specifications and let someone who does know that stuff write the actual code.
-
@Buttembly Coder said:
@Snooder said:
Please read my signature, I believe it applies at this point.@Buttembly Coder said:
I think you're trying to apply my "most every" to a theoretical "every". Obviously there are asinine corner-cases where someone has a truly novel need for a system, but those are almost always so small that the person really could just use excel. A database of business contacts, a database of sales records, an invoicing system, etc, etc, etc,.. These all already exist, and in most cases would be the proper tools. Most of them are fucking terrible, and usually hideously expensive for what they do. In the examples you provide, there's really nothing more complicated in need than an "add a field: name/value" button on the "add a person" form.
Really? Without even looking into the format of the data we're talking about, you jump right to "add a new field" Hell, you don't even know what form the underlying data structure is. I can fucking guarantee you that integrating health record data in any useful form would take a great deal more than just "add a new field." I mean, how would you include say 12 years of sexually active medical records for a 30 year old into a single field? Let's say you instead have a ton of new fields. What happens when you have Kareem Abdul Jabbar using the app and he has a couple thousand entries each with 10 or more years worth of medical visits and tests? What if you only have a few people in your black book, but one of them happens to be Sasha Grey? Dealing with things like that is important, and is the sort of thing that professionals at building databases are taught to do. And for which they need appropriate tools to let them handle doing.If you have to resort to ridiculous examples to make your argument, that means your argument is ridiculous.
If you think that a substantial subset of the people who would actually use a little black book app don't either (a) have a very large contact list, or (b) have slept with a pornstar, I don't know what to say to you.
-
@anotherusername said:
No. She might be able to follow a rather inflexible scripted path written by a brilliant application designer, but the mark of brilliance is understanding the tools better than the average person, and no amount of hand-holding will produce that in someone. A brilliant designer has to be motivated to figure out how things work and exploit them in creative and new ways.
Brilliant application designers understand the average person. Understanding the tools is secondary.
-
@Snooder said:
@blakeyrat said:
@Buttembly Coder said:
Programmers have had at least 50 years to make good software, and I think all we've proven is that we suck at our jobs.
Right! Hell, receptionist Dave at the front desk might turn out to be a brilliant application designer if we could only give him the tools he needs in a form he understands!
And that's the bullshit I'm trying to get you to see past.
See, there's a difference between an "application designer" and a "software architect." Dave can have a really good idea, and know exactly what his userbase wants. But if he doesn't have the talent or drive to learn how to write code, he's never going to actually understand it. The best we can do is dumb down the process and abstract away enough things for him to believe that he understands when he's actually clueless.
I know plenty of MBA types who are great "application designers." They are shit coders, and I wouldn't trust them with a compiler in a millions years. More importantly though, they don't need to be good coders. They can get a good coder to do that stuff for them while they focus on the things they are actually good at doing. Sure, if they are also good at writing software, then they can do both, but if they aren't good at writing software, ruining software development tools to cater to them is not the answer.
I've met great software architects. I don't just mean the guy who manages to squeak out some project under a deadline without too many bugs. I mean the guy who can take a system, sit down and understand the underlying processes well enough to identify places that need to be improved. Or can take an idea sit with it for a while and come up with a completly novel and revolutionary approach. The kind of guy who comes up a brand new algorithm that wins Turing awards. I'm not that great. Even on my best day, I'm a pale shadow of that. But that's what I aspire to be, and what every one else in this profession should aspire to. Software tools should be written for and usable for those people. Not for the sort of guy like Dave who doesn't know shit about math, cares fuck all about algorithms, has no idea what a data structure is, doesn't understand recursion, is completely ignorant of locking and multi-threading, and just wants to make the pretty lights move in a specific direction. That guy should write his specifications and let someone who does know that stuff write the actual code.Why on Earth should being a good software architect require being a good "coder"? Why does your definition of software immediately assume it's written in some programming language and compiled? Why do you continuously assume that a programmer should have knowledge of underlying systems, data structures, and procedures? I don't have to know the file table structure for NTFS to open a file in Windows. I don't have to care about what buttembly code some bit of C compiles to. I don't have to know what processor model the user has to write a program that runs on it. I haven't had to use relational calculus since graduating Uni.
As programmers, we almost always are using abstracted, simplified tools, because they make us more efficient, and cost-effective. If I made the claim that anything you write in non-native code, that doesn't run bare metal is shit, and that you should feel bad for not writing buttembly or lower-level, and that you should never be writing anything, I've just made a completely false and asinine statement. There's no reason that the tools for making programs can't be abstracted far enough, with enough "premade" parts, that a non-coder could use them.
-
@Snooder said:
(snipped)
If you think that a substantial subset of the people who would actually use a little black book app don't either (a) have a very large contact list, or (b) have slept with a pornstar, I don't know what to say to you.
And such apps already exist, so what's the problem? Like I said, it's ridiculous to argue over it.
-
@blakeyrat said:
@anotherusername said:
No. She might be able to follow a rather inflexible scripted path written by a brilliant application designer, but the mark of brilliance is understanding the tools better than the average person, and no amount of hand-holding will produce that in someone. A brilliant designer has to be motivated to figure out how things work and exploit them in creative and new ways.
Brilliant application designers understand the average person. Understanding the tools is secondary.So is there any class of person to whom a particular tool needn't be usable for? Is there something fundamentally wrong with a hammer because it can't be used by a man without arms? If someone cannot understand a problem, does it matter what sort of tool they try to use to solve it?
-
@blakeyrat said:
@anotherusername said:
I think you're confusing brilliant application designers with something else that doesn't involve actual application design.No. She might be able to follow a rather inflexible scripted path written by a brilliant application designer, but the mark of brilliance is understanding the tools better than the average person, and no amount of hand-holding will produce that in someone. A brilliant designer has to be motivated to figure out how things work and exploit them in creative and new ways.
Brilliant application designers understand the average person. Understanding the tools is secondary.
-
@Buttembly Coder said:
Why on Earth should being a good software architect require being a good "coder"? Why does your definition of software immediately assume it's written in some programming language and compiled? Why do you continuously assume that a programmer should have knowledge of underlying systems, data structures, and procedures? I don't have to know the file table structure for NTFS to open a file in Windows. I don't have to care about what buttembly code some bit of C compiles to. I don't have to know what processor model the user has to write a program that runs on it. I haven't had to use relational calculus since graduating Uni.
Much of that is simply because after learning that stuff, it's become unconscious. This is like talking to someone who thinks that math and science are worthless "because I don't use it daily." When in fact, the simple act of applying for a car loan, requires what would have been very advanced algebra a couple of hundred years ago. Just because Quicken exists doesn't mean that an accountant doesn't need to learn math. Or that it's possible to do without accountants.@Buttembly Coder said:
As programmers, we almost always are using abstracted, simplified tools, because they make us more efficient, and cost-effective. If I made the claim that anything you write in non-native code, that doesn't run bare metal is shit, and that you should feel bad for not writing buttembly or lower-level, and that you should never be writing anything, I've just made a completely false and asinine statement.
Good thing I'm not saying that at all then.
@Buttembly Coder said:There's no reason that the tools for making programs can't be abstracted far enough, with enough "premade" parts, that a non-coder could use them.
Yes, there is. There is a difference between abstracting away part of the tools for making programs to focus more in depth on the underlying theory; and abstracting away parts to make it easier for people who don't understand the underlying theory. The progress in software development has been the former, what you and blakeyrat are advocating is the latter.
See, a complex program written in C is no less arcane than one written in x86 or even machine code. It's better because it can do more with less effort, but it still requires training and knowledge to write. A program written in Ruby by the same token is also no less arcane than C, but it does more with less effort. No matter what, as software programming languages and tools get better, so too will the things that are done in them by professionals get more complex to take advantage of that. 60 years ago, getting a computer to do simple multiplication was a triumph. Now, any child can do that, and the professionals are busy with other things. Doesn't mean that professional training is no longer needed, and the same will be true in 60 years. Sure, the code we write now will be trivial in 60 years and any idiot can probably write it using the tools that will be available. But the software devs of that time won't be writing the same code. They'll be writing something even more advanced that we can't even concieve of doing right now. Maybe there'll be a breakthrough to make parallel computing easier for mortal minds to grok. Maybe we'll all be working with AI to write programs that write programs. Maybe we'll have switched to organic computing and be designing living computing systems. Making current programming projects easy enough for a child to understand isn't the goal, the goal should be allowing professionals to make even more complex and better code.
-
@Snooder said:
The simple act of applying for a car loan, requires what would have been very advanced algebra a couple of hundred years ago.
They didn't have cars (as we know them) hundreds of years ago, actually, so that's a very silly point to make.
@Snooder said:Good thing I'm not saying that at all then.
Your whole point has been that programming tools should be complex because people who write programs have to be smarter and better trained. You don't justify why this is. I'm equivocating your claims with equally ludicrous ones.
@Snooder said:There is a difference between abstracting away part of the tools for making programs to focus more in depth on the underlying theory; and abstracting away parts to make it easier for people who don't understand the underlying theory. The progress in software development has been the former, what you and blakeyrat are advocating is the latter.
I advocate programming tools that are geared towards correctness. That is, tools that make The Right Way trivial, and The Wrong Way complex and arcane. Python versus PHP.
@Snooder said:See, a complex program written in C is no less arcane than one written in x86 or even machine code.
And that's what makes C a shitty tool.
@Snooder said:It's better because it can do more with less effort, but it still requires training and knowledge to write. A program written in Ruby by the same token is also no less arcane than C, but it does more with less effort.
And yet,Python manages to be both less arcane, and requiring of less effort. No wonder it' shows up on this site less. Meanwhile, MUMPS manages to be far more arcane, but arguably more powerful, and yet no one wants to work with it. Arcaneness is a bad thing.
@Snooder said:No matter what, as software programming languages and tools get better, so too will the things that are done in them by professionals get more complex to take advantage of that.
You're getting so very close to understanding what I'm saying, but still trying to deny it. Good tools accumulate over time. We don't have to build a database, a file system, and a kernel just to launch grumpycat.exe. The tools evolve, become more robust and simpler, and most importantly, gain coverage of the needed solution space.
While there are still new needs popping up, it's almost impossible to actually find a problem that hasn't been solved before at some point. That's why most programmers use standard libraries, rather than rolling their own floating point math every time.
How much of the code you write is something you've written before, at the "snippet" level? Do you honestly find yourself not repeating anything?
My whole point is that I do not believe there is a lower bound to "necessary" complexity or oddness. "Building" a program should, in hyperbolic terms, be no fundamentally different from building a house out of lego blocks, it should simply be a set of pieces, already solved problems, that are assembled by someone.
Addendum:
Out of curiosity, when is the last time you saw some programming tool and thought "This looks complex, I guess I wasn't meant to use it.", instead of "This tool is a fucking mess, who the hell would use it?"?
-
@Buttembly Coder said:
@Snooder said:
It's better because it can do more with less effort, but it still requires training and knowledge to write. A program written in Ruby by the same token is also no less arcane than C, but it does more with less effort.
And yet,Python manages to be both less arcane, and requiring of less effort. No wonder it' shows up on this site less. Meanwhile, MUMPS manages to be far more arcane, but arguably more powerful, and yet no one wants to work with it. Arcaneness is a bad thing.
To someone who doesn't know Python, Python is damn arcane. It's not any less inscrutable to the "average untrained user" than C is, or even x86 for that matter. Don't believe me? Walk up to some random person in the street, show them a sheet of Python and ask them what it does. See how many correct answers you get. @Buttembly Coder said:How much of the code you write is something you've written before, at the "snippet" level? Do you honestly find yourself not repeating anything?
My whole point is that I do not believe there is a lower bound to "necessary" complexity or oddness. "Building" a program should, in hyperbolic terms, be no fundamentally different from building a house out of lego blocks, it should simply be a set of pieces, already solved problems, that are assembled by someone.
I think we're talking about two slightly different things here. I agree with you that much of the code you use to assemble a program in this day and age is built by other people. We stand on the shoulders of giants and all that.
Where we part is that I don't consider that part to be the important part of software development from the perspective of the programmer/developer. Regurgitating the same solutions that someone else has already done is not our job. It's not difficult, and it's not the thing that people actually need. Yeah, nobody needs the umpteenth version of a date library. But, software development tools shouldn't be designed for non-developers to slap together stuff that real developers have already created to fix problems that everyone already knows the solution to. Software development tools should be designed for developers to create those fixes in the first place.
You seem to be thinking that there will some theoretical point in the future where every single problem that can be solved by software will already have been. I'm telling you that is IMPOSSIBLE. As in literally against the laws of reality. It's impossible to solve every problem that can be solved by software because the set of those problems is infinite in size and ever expanding.
-
@Snooder said:
Where we part is that I don't consider that part to be the important part of software development from the perspective of the programmer/developer.
You have an extremely narrow definition of the word "developer", I think might be part of the problem here.
@Snooder said:
Regurgitating the same solutions that someone else has already done is not our job.
Sure it is. Vegas made shitloads of cash taking video editing and encoding software and actually making it usable. All that stuff existed before Vegas, right? So by your definition, either Vegas wasn't made by "developers", or there was no need to create Vegas. I believe both are demonstrably false.
@Snooder said:
It's not difficult, and it's not the thing that people actually need.
The thing that's difficult is making the thing that's difficult easy.
The easy thing is making something difficult. For example, I'm sure designing Git was easy for Linus Torvalds and party, because they didn't spend one iota of brainpower thinking, "hey, how do we make this easy-to-use?" GitHub has made tons of money taking that shitty-ass Git codebase and making it easier to use. Trying to at least, it's a hopeless task. Do you think the people who write GitHub for Windows aren't developers?
@Snooder said:
You seem to be thinking that there will some theoretical point in the future where every single problem that can be solved by software will already have been.
That's not the end-goal, for me at least. The end-goal for me is that every single problem Bob has will be easily solvable by Bob himself.
-
@blakeyrat said:
That's not the end-goal, for me at least. The end-goal for me is that every single problem Bob has will be easily solvable by Bob himself.
Yeah, and I think where we fundamentally disagree is that I don't think that's possible either. At some point, I think Bob will run into a problem that requires a software development to solve because it won't have already been solved by a previous developer. And if Bob doesn't have the training to be a developer, it doesn't matter how easy the tools are, he won't be able to solve his problem himself.
-
@Snooder said:
Yeah, and I think where we fundamentally disagree is that I don't think that's possible either.
Irrelevant.
Possible or not, that should be our goal.
-
@Snooder said:
To someone who doesn't know Python, Python is damn arcane.
Exactly. The programming tools currently available are not, say it with me, "usable".
@Snooder said:
software development tools shouldn't be designed for non-developers to slap together stuff that real developers have already created to fix problems that everyone already knows the solution to..
If everyone knows the solution, then non-developers know the solution as well. Don't spew words that confound your own point.
@Snooder said:
I think we're talking about two slightly different things here.
Mostly since you seem to not be reading my posts very well:
@Snooder said:
You seem to be thinking that there will some theoretical point in the future where every single problem that can be solved by software will already have been. I'm telling you that is IMPOSSIBLE. As in literally against the laws of reality. It's impossible to solve every problem that can be solved by software because the set of those problems is infinite in size and ever expanding.
I could make all sorts of Church-Turing arguments you wouldn't understand, computability discussions that would fly over your head, or even just bullshit at you if I wanted. But, no, that's not even close to what I've been saying. I've pointed out a few times in this thread that there will always be corner cases, there will always be novel problems. Your refusal or inability to read is not my fault, and I'm not arguing that point any more.
@Snooder said:
Software development tools should be designed for developers to create those fixes in the first place.
A quick back-of-the-envelope calculation says that the number of man-years spent developing software so far exceeds the year-age of the human race, and yet, in spite of this, most software out there is complete shit. I think it's demonstrable that developers, as a whole, cannot be trusted to make anything, and will continuously rebuild the wheel with larger and heftier system requirements, more dependencies, and more bugs. All while blaming the user.
-
@Buttembly Coder said:
@Snooder said:
To someone who doesn't know INSERT_ANY_LANGUAGE_OF_ANY_KIND, INSERT_ANY_LANGUAGE_OF_ANY_KIND is damn arcane.To someone who doesn't know Python, Python is damn arcane.
Exactly. The programming tools currently available are not, say it with me, "usable".
That's a fact of languages, not programming languages. That's like saying male humans are smelly when you really meant all humans are smelly.
-
@blakeyrat said:
@Snooder said:
Yeah, and I think where we fundamentally disagree is that I don't think that's possible either.
Irrelevant.
Possible or not, that should be our goal.
No, it shouldn't. The goal for a tool designed for a professional programmer should be one that helps said professional programmer. Not to cripple the professional in a misguided attempt to uplift the non-professional. Simplifying down the process of writing code, and abstracting away many of the pieces of it into specific little building blocks that any idiot can use inevitably means that crafting custom solutions is made more difficult. Buttembly I think understands that a bit better, he simply assumes incorrectly that the corner cases where the professional is restricted are not important. I'm trying to explain that the professional's job is to generate solutions for those corner cases, so being restricted there is extremely detrimental to his job performance.
@Buttembly Coder said:A quick back-of-the-envelope calculation says that the number of man-years spent developing software so far exceeds the year-age of the human race, and yet, in spite of this, most software out there is complete shit. I think it's demonstrable that developers, as a whole, cannot be trusted to make anything, and will continuously rebuild the wheel with larger and heftier system requirements, more dependencies, and more bugs. All while blaming the user.
Most software is shit simply because most things are shit. Such is the human condition. What does that have to with whether or not all software development tools should be simplified into pre-fab building blocks (and therefore less useful for building custom solutions) for people who don't have the training, skill or knowledge necessary to use more general tools?
Look, you (and Blakeyrat) seem to be arguing for the extension of WYSIWYG style tools for the masses so they can accomplish tasks that have been made trivial by the advancement of computing. And, as far as that goes, I have no argument with that.
What I have an argument with is trying to make those sorts of tools the primary ones for software developers whose job it is to resolve those "corner cases." That's short-sighted and ultimately detrimental to getting any real progress.
-
@Ben L. said:
@Buttembly Coder said:
@Snooder said:
To someone who doesn't know INSERT_ANY_LANGUAGE_OF_ANY_KIND, INSERT_ANY_LANGUAGE_OF_ANY_KIND is damn arcane.To someone who doesn't know Python, Python is damn arcane.
Exactly. The programming tools currently available are not, say it with me, "usable".
That's a fact of languages, not programming languages. That's like saying male humans are smelly when you really meant all humans are smelly.
To someone who doesn't know American English, British English is hardly "arcane". To someone who knows Portuguese, Spanish is hardly "arcane". To someone who knows Javascript, Perl is... well, anyways. To someone who knows Java, C# is hardly arcane. There are a number of languages that are similar enough in terms of rules to what people already know to be simple to learn. There have already been natural language processors that attempt to generate programs from English-language descriptions. But, really, it's pointlessly restrictive to assume that "making a program" has to be "writing code". Especially as a number of people already use Visual tools to make parts of them.
The point is that you can make "developing a program" easy enough that no "arcane" knowledge is required, only general knowledge.
-
@Snooder said:
...What does that have to with whether or not all software development tools should be simplified into pre-fab building blocks (and therefore less useful for building custom solutions) for people who don't have the training, skill or knowledge necessary to use more general tools?
Look, you (and Blakeyrat) seem to be arguing for the extension of WYSIWYG style tools for the masses so they can accomplish tasks that have been made trivial by the advancement of computing. And, as far as that goes, I have no argument with that.
What I have an argument with is trying to make those sorts of tools the primary ones for software developers whose job it is to resolve those "corner cases." That's short-sighted and ultimately detrimental to getting any real progress....When, exactly, are you thinking I made such an argument? I've been arguing for the existence of such tools, not the exclusion of others.
Addendum
I'm also trying to point out that, since many tools available currently are geared equally towards doing things The Wrong Way as they are The Right Way, the development of tools more geared to doing things The Right Way would tend to make for more Good Software, regardless of the creator. Additionally, I don't believe most developers now can be trusted with the currently-available tools.
Second Addendum
I am arguing against the use of C, however. Also PHP. C++ can go fuck itself, too.
-
@Snooder said:
No, it shouldn't. The goal for a tool designed for a professional programmer should be one that helps said professional programmer. Not to cripple the professional in a misguided attempt to uplift the non-professional.
Those two things are not mutually-exclusive.
@Snooder said:
Simplifying down the process of writing code, and abstracting away many of the pieces of it into specific little building blocks that any idiot can use inevitably means that crafting custom solutions is made more difficult.
How do you figure?
Edit: BTW what you've just described is basically exactly what the creators of object oriented programming had in mind when they designed it. (It didn't work out because they fucked-up the implementation. But that was the original concept.)
@Snooder said:
What does that have to with whether or not all software development tools should be simplified into pre-fab building blocks (and therefore less useful for building custom solutions) for people who don't have the training, skill or knowledge necessary to use more general tools?
He's just saying (if I may interpret) that, demonstrably, the current system does not work. Since your argument is basically, "status quo! Status quo!" this is pretty relevant to the debate.
@Snooder said:
Look, you (and Blakeyrat) seem to be arguing for the extension of WYSIWYG style tools for the masses so they can accomplish tasks that have been made trivial by the advancement of computing. And, as far as that goes, I have no argument with that.
They don't have to be WYSIWYG, they just have to be usable.
@Snooder said:
What I have an argument with is trying to make those sorts of tools the primary ones for software developers whose job it is to resolve those "corner cases." That's short-sighted and ultimately detrimental to getting any real progress.
I don't understand your objection, though. It seems to rely on the misconception that it's impossible to make a single program that can be used both by "software developers" (whatever your definition of that is) and average joes at the same time. But you've never demonstrated why a single program can't work for both parties. So... why can't it?
