Sigh. WayTools has previously stated that their infrastructure rewrite was limited to feature parity with the current firmware. (Good!) But now I see on the WayTools Forum that they are adding new features to it (e.g. new sticky modifier keys; ability to use it while wired; etc.). *head in hands*.
From the way they wrote it, we can't tell if the sticky is before or after GR. Same applies to most things they've talked about.
I have no doubt but that some things can be "added" which really aren't much in the way of additions that could cause problems. For example:
We have 6 jump slots. More are apparently coming. Is this a new addition to be concerned about? It would depend on several things, but to take a simple example, consider a spreadsheet where you have a formula which looks a cell in 10 rows. When it finds a match, it takes info from other cells in that row.
But then you decide you want 20 different options. Well, it is no problem to change the formula to search through 20 rows. There is no risk here of screwing up some other routine. Jumps could work like that. It checks the chord you hit for the jump slot and when it recognizes it, it connects to the info that goes with it.
Even if it didn't work that way originally, a rewrite reduces the code may well make it work that way. I have a real life example of that. Many years ago, when we'd get computer magazines which had program listings in BASIC we would enter into our computers manually, I saw one that was about word jumbles. Those were things you saw in newspapers that, I think, had either 5 or 6 letters jumbled up and the reader would try to unjumble each one. Well, the code was written to handle those two situations and it was written so the first thing it did was see if you entered a 5 letter or 6 letter word. It would then jump to the part of the code which dealt with that length - the two parts of the code were essentially identical except for the number of characters it dealt with. Very wasteful and also limited.
So I rewrote it and, by using variables, you could enter any size word (thus not limited) and with no need to duplicate code (thus not wasteful). This means that even if jumps were developed in a way where adding more would be complicated, the necessary change to free up space could also mean they could add more with no additional complication or impact on other things.
The point is, if that is how more slots come about, is that really adding anything new? It could be argued both ways, but since the concern is about adding new things causing delays, in this example, if accurate, I'd say "no". Other things I can't even theorize since I don't have any idea about what they involved.
Yes, sounds great, but couldn’t the above be work done by Mark’s developers while the rest of his customers are actually using TextBlades, and then offered to customers via a firmware update?
That’s the whole point of firmware updates. It’s beyond obvious that there could have been at least a couple of years of firmware updates and at least a couple of years of actual usage, but instead, as has been said before by others, we have an endless feature creep, optimisation process, ageing Li-Ion batteries and more.
The ability of Mark and his investors to keep shovelling money into a company producing no returns and potentially ever fewer pre-orders is also in continual question for customers.
That concern prompted me to cancel, despite my still wanting a TextBlade, and despite the “free gift” causing me to hold off.
In the end no free gift was worth the worry that Waytools would go by the wayside, I didn’t order a TextBlade to get a free gift, I ordered a TextBlade to get a TextBlade.
I ended up cancelling, which allows Mark to gleefully point out that I am “no longer a customer” and allows him to question whether I am a secret agent from Logitech looking to besmirch and destroy Waytools and Mark’s reputation.
Sadly for Mark he is doing that all by himself. 800+ posts because Mark can only communicate in anger, and in conspiracy talk etc etc etc etc.
As Rolanbek so wisely stated, all some of us ever wanted was a small keyboard.
There are great questions and observations from a range of commenters above.
Sadly we know Mark will ignore 99.9% of those, will find a word or two to get outraged about, will throw an insult or two here or there, will remind some of that that we’re not even customers, and well, we all know the drill, only too well.
The only surprise left in Mark’s arsenal beyond bad ones of further delays is general release, or GR.
Otherwise that’s it, we’re stuck in one of Dr Strange’s time loops, and we can all come back here in 2020, 2021 and just end up in a Catch 2022 situation.
I’d ask Mark to prove us wrong, but I already did, and he didn’t.
Mark, don’t bother responding, any of us here can copy and paste one of your previous responses.
I might start doing doing that in future to predict what you might say and to save you the time so you use that time in the evenings to live life, sleep, or do something more productive.
We have 4+ years of Waytools_Support responses to copy and paste from.
Here’s one I took a few seconds to piece together.
We’re sorry that our communication did not please you. Please consider whether the tone of your own posts would feel reasonable if you were on the receiving end.
You’ve always controlled your money. Just push the button and take it back if you don’t believe in our good faith.
Since you’re still engaged on topic, we hope that you’ll ultimately have a good experience with a unit, and are very happy.
Hopefully you’ll quite like it when you can try a TextBlade for yourself. Thanks.
We didn’t initiate, we only responded.
It would be really nice for everyone if there we’re (sic) no attacks to answer.
etc etc, dum spiro spero, docendo discimus, eheu fugaces labuntur anni, 仕事に戻る, et cetera
I have no doubt but that some things can be "added" which really aren't much in the way of additions that could cause problems. For example:
When we write software, we always *think* that this or that minor change or addition won't cause problems. Sometimes we can't see how it could possibly cause problems (like your Excel example), yet it still causes bugs (say from a memory management issue, or it causes a reference collision, or now the new number introduces a divide-by-zero that wasn't previously present, etc.). Sometimes you even write code that is logically identical and yet somehow it introduces a bug anyway! Then it requires weeks track down the bug and figure out the edge cases and fix the bug and test the fix and then track down the bugs from the fix and figure out the edge cases from the fix and...
Even when the feature looks like it's been implemented successfully, you still have to test it anew internally. And then check for interactions with any other new code you've written. And then push a new build. And then stress test it externally. And, as they've said, the design and UI of it needs to be carefully crafted to begin with, and that takes time too. Etc. Etc.
In any project, it always seems like it'll be so simple. "What could possibly go wrong?"
I don't know any competent software project manager who thinks that you can add features (no matter how small) without extending the deadline. Hard-won experience from every PM is that the only way to stop the cycle to is to do a for-real feature-freeze and not be wishy-washy about it.
When programs are simple, bugs are relatively easy to find and squash. But by all accounts, the TextBlade firmware is amazingly complex (which it would have to be in order to support its revolutionary capabilities). Adding a feature to code_block_A seems simple enough and could be perfectly fine on its own (like the BASIC word-jumble upgrade example). But then code_block_B expects code_block_A to work more narrowly and that causes a bug.
But more realistically, in a project this size, code_block_B is fine with it, but code_block_C depends on B, and D depends on C and...Z depends on Y, and it is code_block_Z that expects code_block_A to work the old way and throws a bug.
And then 1 out of a hundred testers trips over this bug, but it is nearly impossible to reproduce. But WayTools cares very much about this level of quality, so they can't just let it slide. And they can't just revert the code, because now code_block_J and code_block_Q rely on code_block_A working the *new* way. So it takes weeks to find a way to reliably reproduce the bug, and more time to fix it, and then more time to test it, which uncovers more edge cases, which requires weeks to reliably reproduce the bug, which requires...
Yes, sounds great, but couldn’t the above be work done by Mark’s developers while the rest of his customers are actually using TextBlades, and then offered to customers via a firmware update?
I've addressed that point before. I think the order of some things is causing confusion so let me try to detail that.
1. It seems reasonable to say that it is only the present firmware that we have in Treg that WT has considered to be "good enough". At least they never said that about any other version.
2. That being the case, and since that version came out in, I think, September, that would be the earliest they could have shipped. But even that wouldn't be true since they couldn't know it would pass their standards until after it had passed enough of their own and enough Treg testing to confirm they had achieved that goal. I don't think there is any chance that could take less than a month no matter how good the testing was over the first 2-3 weeks. Because they have surely learned that problems have popped up many times before. So that moves us to sometime in October, AT BEST. The point here is that we wouldn't have had it for years, but 7 months at best and maybe much less! I've seen plenty of people declare it would take at least 6 months of such testing, so that would mean it would only be released 2 months ago! Just narrowing down the areas to complain about
3. But by then they also knew they had a huge problem with space. No matter how good testing turned out, sending it out to tens or even hundreds of thousands of customers, issues are going to show up!
It is, in my opinion, we get to the question of what they should have done. I also submit there is no "right" answer as both involve big risks to the company. In short, do they ship and let people suffer with issues they can't fix readily because of the need to rewrite not only the "bug" part, but other things to make room for the fix, or do they free up the space first by rewriting and testing.
The first gets it out the door and makes many people happy. But it may also make a lot of people unhappy because of issues a rewrite would eliminate or minimize.
The second makes people who are tired of waiting even angrier. But, to be honest, most people who ordered probably aren't even thinking about it - may have even forgotten about it. So the people becoming angrier are going to be a fairly consistent number who were also angry years ago. So, as a BUSINESS decision, the greater risk may well be viewed as having a lot of customers complaining about some problem they run into and WT not being able to deal with the problems quickly.
And remember, a lot of these "problems" are really going to be user error. I can't emphasize that enough, but because of how it works, they ARE going to think it is the product rather than themselves. So they'll have a base percentage of user support demands that aren't the fault of WT. The more they can limit those issues that ARE something they can fix ahead of time, the better.
Add in the slowdown in development of the new firmware if they are also actively trying to rewrite, piecemeal, the firmware any time a new issue is reported and you have a real mess.
To me it isn't about which approach they SHOULD do because, as I said, I don't think there is a definitive "right" answer. To me it is about whether the decision they make seems to make sense and I think it does. But if they said they decided to ship today, I'd be fine with that too.
When we write software, we always *think* that this or that minor change or addition won't cause problems. Sometimes we can't see how it could possibly cause problems (like your Excel example), yet it still causes bugs (say from a memory management issue, or it causes a reference collision, or now the new number introduces a divide-by-zero that wasn't previously present, etc.). Sometimes you even write code that is logically identical and yet somehow it introduces a bug anyway! Then it requires weeks track down the bug and figure out the edge cases and fix the bug and test the fix and then track down the bugs from the fix and figure out the edge cases from the fix and...
Yes, all that is possible. But the risk for some things is pretty darn small.
But let's say it isn't. Think about what that means if they didn't do the rewrite! Most fixes will tend to take more memory, forcing a rewrite of unrelated items. And so every time one thing has to be fixed, you are not only risking things from the change to fix the bug but another change to make room! It could require even more than one other change, but regardless, you are doubling, or more, the chances of creating a new issue.
That's not my point. My point is about the necessity of a feature freeze.
You are pointing out something so obvious, it seems inconceivable they did not know it, or learn it, many years ago.
Imagine for a moment, actually working for Mark Knighton as a software developer. Consider the way he communicates, and then imagine working under someone like that. He has probably gone through at least 2 or 3 developers since the inception of this project and driven a couple of poor bastards insane in the process. He probably kept asking the developers to add more and more and more features, year after year, until one finally snapped, fired up 'Take This Job and Shove It' by Johnny Paycheck on Youtube, set the volume to 11, and screamed at him 'It is full !!!! Nothing and I mean nothing else is going to fit in your 5 year old hardware!! I quit!' and stormed out of the building to find a new less stressful career, like gathering acorns for disabled chipmunks in the forest.
It's definitely in the same voice as Waytools_Support. It shows the kind of inanity we see from Waytools_Suppport was there from the beginning.
The attempt at an "I am Iron Man" ending is funny.
Given my penchant for rewrites, it should be rewritten:
"My name is Mark Knighton, and I run WayTools into the ground".
Original is below. The voice is unmistakably Waytools_Support, and remember, this post from March 13, 2015, is essentially the same post Mark has rewritten hundreds or even thousands of times since, and we see the seeds of Oppo-PR paranoia being sown below. As with so much about Waytools, it is absolutely astonishing.
Let us also remember Mark's first sentence below, and rewrite it again: "The magnificence of the internet is that it gives everyone a voice. That is why we have the Waytools Forum, where we can silence the voices of those we don't like - at will. You have been warned, shadow banning is what we do."
As one who was unjustly shadow banned, I know from personal experience.
+++
The magnificence of the internet is that it gives everyone a voice.
Even the quieter voices can out the truths that deserve to be heard.
With this freedom and power, also comes hazard. Anyone can claim anything, without any evidence. Even diametrically untrue things, carefully contrived for commercial interest.
They can do all of this anonymously, with an artificial persona, and no real identity at all. This new reality requires that we discern for ourselves what we consider to be credible.
A few personal observations based on logic -
A company that gives customers direct control over refunds at all times, does not suggest dishonesty.
A customer who is not pleased, cancels. They generally don't spend their time writing public diatribes misrepresenting dates and communications. (like this).
A poster who cites unrelated horror stories, and then knits them to their target, has a purpose in mind.
And, unfortunately, established players worried about a disruptive technology, really do pay operatives to discredit a promising change.
I think consumers would prefer to see effort go instead toward making great products.
2. ...I don't think there is any chance that could take less than a month no matter how good the testing was over the first 2-3 weeks. Because they have surely learned that problems have popped up many times before. So that moves us to sometime in October, AT BEST. ...
You are finally getting it. This is why I was insisting years ago that their estimate of "this month" (for any given month when they said it) was unrealistic (especially when it was the last week of that month) and that they needed to give real, honest estimates instead of the automatic "next [time period]" estimates which is what they (presumably) thought we wanted to hear.
I argued that their estimate-making process was broken since it always outputted "next [time period]" even if the input was something along the lines of "we just discovered a hardware issue that requires a serious overhaul and redesign of the butterfly switches". Somehow you interpreted that as me arguing that they should make less *frequent* estimates instead of a call for an overhaul of how they make their estimates in the first place.
And remember, a lot of these "problems" are really going to be user error. I can't emphasize that enough, but because of how it works, they ARE going to think it is the product rather than themselves. So they'll have a base percentage of user support demands that aren't the fault of WT. The more they can limit those issues that ARE something they can fix ahead of time, the better.
This is mindboggling and ironic since this was originally one of my complaints on the WayTools Forum--which was that no amount of firmware improvements will solve user error. Somehow you've managed to twist it backwards into a rationale that essentially demands perfection (even though you and WayTools have explicitly said that they are not demanding perfection). With this thinking, no matter what, it is always justified to delay for improvements for the sake of people who will blame WayTools for their own errors regardless.
They say they don't require perfection to ship, but every visible action and all of their other stated rationales that I've seen indicate that they think otherwise. And all of your statements indicate that while you would be happy for them to ship now, you are also fine with them delaying any amount of time to reach any arbitrarily high level of quality that they are satisfied with (i.e. perfect in all but name).
To me it isn't about which approach they SHOULD do because, as I said, I don't think there is a definitive "right" answer. To me it is about whether the decision they make seems to make sense...
Well that's the thing, *all sorts of things* can be justified as BUSINESS decisions, especially unethical ones. When we complain about what they SHOULD do, that generally implies ethics, not business. Of course there is overlap, but just saying that X decision "seems to make sense" from a business standpoint makes for a crummy ethical stance.
Wow! That is epic! Thanks for digging that up--I had forgotten about it. It is amazing how consistent he is.
"My name is Mark Knighton, and I run WayTools."
I can totally hear that in RDJ's voice.
Rolanbek found it, and TBD noted it as well, see the first post on this page way above
I don’t hear RDJ’s voice. I hear Thanos, or some other villain. Mark “Khaleesi S08E05” Knighton is definitely not my hero, but a great example of how not to run a business, how not to do PR, how not to do customer support, how not to live life and how not to be a person or a man, and how not to smugly read this and still think with a smirk he’s heroic TextBladeMan.
Mark is a great example of how to be consistent though, as you point out. There’s always a silver lining somewhere, if you stretch hard enough to find the needle of good in the haystack of indifference.
Sigh. WayTools has previously stated that their infrastructure rewrite was limited to feature parity with the current firmware. (Good!) But now I see on the WayTools Forum that they are adding new features to it (e.g. new sticky modifier keys; ability to use it while wired; etc.). *head in hands*.
From the way they wrote it, we can't tell if the sticky is before or after GR. Same applies to most things they've talked about.
I have no doubt but that some things can be "added" which really aren't much in the way of additions that could cause problems. For example:
We have 6 jump slots. More are apparently coming. Is this a new addition to be concerned about? It would depend on several things, but to take a simple example, consider a spreadsheet where you have a formula which looks a cell in 10 rows. When it finds a match, it takes info from other cells in that row.
But then you decide you want 20 different options. Well, it is no problem to change the formula to search through 20 rows. There is no risk here of screwing up some other routine. Jumps could work like that. It checks the chord you hit for the jump slot and when it recognizes it, it connects to the info that goes with it.
Even if it didn't work that way originally, a rewrite reduces the code may well make it work that way. I have a real life example of that. Many years ago, when we'd get computer magazines which had program listings in BASIC we would enter into our computers manually, I saw one that was about word jumbles. Those were things you saw in newspapers that, I think, had either 5 or 6 letters jumbled up and the reader would try to unjumble each one. Well, the code was written to handle those two situations and it was written so the first thing it did was see if you entered a 5 letter or 6 letter word. It would then jump to the part of the code which dealt with that length - the two parts of the code were essentially identical except for the number of characters it dealt with. Very wasteful and also limited.
So I rewrote it and, by using variables, you could enter any size word (thus not limited) and with no need to duplicate code (thus not wasteful). This means that even if jumps were developed in a way where adding more would be complicated, the necessary change to free up space could also mean they could add more with no additional complication or impact on other things.
The point is, if that is how more slots come about, is that really adding anything new? It could be argued both ways, but since the concern is about adding new things causing delays, in this example, if accurate, I'd say "no". Other things I can't even theorize since I don't have any idea about what they involved.
I think you mean something like this (trying to remember old BASIC here):
10 rem ** old firmware ** 20 rem copyright Waytools 2015, 2016, 2017, 2018, 2019 30 let MAXSLOTS = 6 40 dim bluetooth[MAXSLOTS][3] 45 If $action == "switch" then gosub 100 50 if $action == "pair" then gosub 200 60 END 100 rem switch to desired_bt slot 105 if desired_bt > MAXSLOTS then print "max number slots for BT is ";MAXSLOTS;"!!!" 110 if desired_bt < 1 then print "illegal slot number!!!" 120 rem switch to desired_bt slot 130 gosub 300 140 return 200 if desired_slot > MAXSLOTS then print "max number slots for BT is ";MAXSLOTS;"!!!" 210 if desired_slot < 1 then print "illegal slot number!!!" 220 rem pair BT device into desired_slot 230 gosub 400 240 return
For all we know, these were the only code edit they made in several months:
20 rem copyright Waytools 2015, 2016, 2017, 2018, 2019, 2020, 2021 25 rem git push - blame: <Mark Knighton> boss@waytools, reason: 'to justify delays and because I run Waytools, i am nobody's biatch dammit' 30 let MAXSLOTS = 12
"We made great strides, doing complete rewrite, adding advanced features. We worked hard burning the midnight oil for months. We think you'll like it!" -- Waytools (err, Mark Knighton)
And remember, a lot of these "problems" are really going to be user error. I can't emphasize that enough, but because of how it works, they ARE going to think it is the product rather than themselves. So they'll have a base percentage of user support demands that aren't the fault of WT. The more they can limit those issues that ARE something they can fix ahead of time, the better.
At one point, I jokingly predicted that you would claim that a user physically breaking their TextBlade would be justification for delaying GR so that WayTools could make their firmware *that much better* to belay support issues. You wanted to know why I attributed such a silly response to you. Well, it was an extrapolation of the rationale you gave above.
10 rem ** old firmware ** 20 rem copyright Waytools 2015, 2016, 2017, 2018, 2019 30 let MAXSLOTS = 6 40 dim bluetooth[MAXSLOTS][3] 45 If $action == "switch" then gosub 100 50 if $action == "pair" then gosub 200 60 END 100 rem switch to desired_bt slot 105 if desired_bt > MAXSLOTS then print "max number slots for BT is ";MAXSLOTS;"!!!" 110 if desired_bt < 1 then print "illegal slot number!!!" 120 rem switch to desired_bt slot 130 gosub 300 140 return 200 if desired_slot > MAXSLOTS then print "max number slots for BT is ";MAXSLOTS;"!!!" 210 if desired_slot < 1 then print "illegal slot number!!!" 220 rem pair BT device into desired_slot 230 gosub 400 240 return
For all we know, these were the only code edit they made in several months:
20 rem copyright Waytools 2015, 2016, 2017, 2018, 2019, 2020, 2021 25 rem git push - blame: <Mark Knighton> boss@waytools, reason: 'to justify delays and because I run Waytools, i am nobody's biatch dammit' 30 let MAXSLOTS = 12
For all we know, the current Textblade hardware may be comprised of old 6502 CPUs cobbled together from recycled VIC-20s, and the code is written in Microsoft BASIC. Anything is possible.
gosub line # .... lolz. Brings back memories from my pre-teen years when I was doing the same thing that Kahuna often proudly claims as his primary programming experience. Typing code from Compute!'s Gazette magazine into a Commodore 64. That was around 1983 I think. Then I moved on to Apple and Pascal.
That's not my point. My point is about the necessity of a feature freeze.
Yes, but I'm pointing out that feature freeze isn't a rock solid concept. Is 12 jump slots a new feature, or an easy expansion of an existing one?
Then there is the matter that when rewriting, they are obviously going to be not only compacting the code, but in some cases this will require different structures to save more space, which opens up other opportunities. Back to jumps, they may have had to restructure them - which would also allow more of them automatically, which they couldn't do before the restructure. I would think it would be foolish of them to say, "Let's rewrite it to save a little memory, but not as much as to change the structure which will save LOTS of memory - and which would also have the bonus of allowing more jumps". To me it would be logical to change the structure even if it also allowed jumps to exceed "parity".
I can think of many things that could work out this way - but do not KNOW they work out that way since that would require a lot of info we don't know, probably won't ever know and, at least in some cases, we shouldn't know. So I hope the next update will give some insight into this.
> This is why I was insisting years ago that their estimate of "this month" (for any given month when they said it) was unrealistic (especially when it was the last week of that month)
Yep, but back the overall picture was different. Before Treg, they may have well thought they just had to fix a few things (those of us in Treg know they usually did those quickly). During Treg, the new problems found escalated - but they still fixed them quickly once identified. The problem was that problems kept being found and I don't think anyone would have expected that. I disregard the part about "especially the last week of the month" because they weren't making a new estimate - that was the one made at the end of the prior month. They just didn't update the estimates publicly until they reached the deadline for the previous one.
> This is mindboggling and ironic since this was originally one of my complaints on the WayTools Forum--which was that no amount of firmware improvements will solve user error. Somehow you've managed to twist it backwards into a rationale that essentially demands perfection (even though you and WayTools have explicitly said that they are not demanding perfection). With this thinking, no matter what, it is always justified to delay for improvements for the sake of people who will blame WayTools for their own errors regardless.
Not twisting anything. Nor does it have anything to do with making it perfect. Simplified, it goes like this:
1. We can handle X number of customer support issues a day.
2. We can expert Y number (less than X) will be simple user error.
3. We anticipate Z number of problems based on current firmware (let's say in 2017).
4. Y + Z is greater than X. So they have to work to reduce Z. But not to zero (perfection). But enough so Y+Z is no more than X.
> They say they don't require perfection to ship, but every visible action and all of their other stated rationales that I've seen indicate that they think otherwise.
Actually, it only shows they want to make it better than what it is at that moment. Which brings us back to the four items I listed above. In any case, I can assure you then present firmware, which is NOT perfect, they have said is good enough.
> Well that's the thing, *all sorts of things* can be justified as BUSINESS decisions, especially unethical ones. When we complain about what they SHOULD do, that generally implies ethics, not business.
The point I was making was both good business and ethical. That is, I would NOT consider it "ethical" to ship before it is good enough. Where to draw that line may be a matter of opinion, but not of ethics.
dabigkahuna said: Yes, but I'm pointing out that feature freeze isn't a rock solid concept. Is 12 jump slots a new feature, or an easy expansion of an existing one?
Based on that statement, I think its safe to assume that you have never worked on a serious software project before and have absolutely no idea what you are talking about.
A feature freeze actually is a rock solid concept. There are different degrees of freeze implemented at various stages of any successfully managed software project.
As is obvious to all, both you and Waytools (Mark Knighton) have no idea how to go about managing development, hence the absurd 4+ years of consecutive delays.
Kahuna, are you the software team leader on the Textblade project?
Brings back memories from my pre-teen years when I was doing the same thing that Kahuna often proudly claims as his primary programming experience. Typing code from Compute!'s Gazette magazine into a Commodore 64. That was around 1983 I think. Then I moved on to Apple and Pascal.
Wrong again. Sure, I wrote some things in basic. So? If it gets THE JOB done, so what? One of the first things I learned was that there were proficient/expert programmers out there who couldn't write a program that really met the needs of the end user. I'd give examples, but I don't think you'd pay attention. I always focused on the end user and then figured out how to accomplish what they needed.
But what I mostly did - and have posted about - is write in BASIC AND machine code for the best mesh of each (BASIC being simpler/quicker to do, but machine code being faster and often requiring less memory.
It was really quite effective. Using a BASIC line for "Input name" is close enough to doing the same thing with machine code. But machine code paid off in a big way when sorting or calculating, etc. Even had a few full time programmers ask to use some things I worked out.
It was really quite effective. Using a BASIC line for "Input name" is close enough to doing the same thing with machine code. But machine code paid off in a big way when sorting or calculating, etc. Even had a few full time programmers ask to use some things I worked out.
Cool. Post some of your old 'BASIC AND machine code' on Github so we can check it out.
Cool. Post some of your old 'BASIC AND machine code' on Github so we can check it out.
Not likely since the computers I wrote for were decades ago, stored on tape which would have long since worn out, and I don't have the paperwork anymore.
I can certainly tell you what they did and contrast with what I saw available on Apple II series of computers at the time (hint: Mine were faster, held more data, and structured into a more useful form on screen).
Wrong again. Sure, I wrote some things in basic. So? If it gets THE JOB done, so what? One of the first things I learned was that there were proficient/expert programmers out there who couldn't write a program that really met the needs of the end user. I'd give examples, but I don't think you'd pay attention. I always focused on the end user and then figured out how to accomplish what they needed.
But what I mostly did - and have posted about - is write in BASIC AND machine code for the best mesh of each (BASIC being simpler/quicker to do, but machine code being faster and often requiring less memory.
It was really quite effective. Using a BASIC line for "Input name" is close enough to doing the same thing with machine code. But machine code paid off in a big way when sorting or calculating, etc. Even had a few full time programmers ask to use some things I worked out.
Ah yes, this reminds of the discussion you and I had many moons ago.
You never did answer my questions about how you accomplished the things you claim. Just to be sure, you're claiming you wrote some grading program (a mix of BASIC + machine language code) on your Apple II that did some math for you (IIRC).
My questions were:
Which model of Apple II was it? Just II, or II+, or IIe?
Which version of BASIC did you use? The Integer BASIC or Applesoft?
Which portion (BASIC or the machine language code) did the math calculations? Since there was this speed increase, I'm assuming the machine language code did. So then...
How did you enter the machine language portion? Did you punch them in by hand using Hex into monitor? Or what assembler/disassembler did you use? or did you peek and poke each value of the machine language code from BASIC?
How the heck did you debug the machine language code
How did the BASIC program communicate with the machine language portion and vice versa?
What memory area (approximately) did the machine code occupy?
How were you able to do decimal math at using binary? How did you store them and what were the precisions, esp the fractional parts?
The reason why I ask the last one is because doing decimal math via binary is not for the faint of heart. It takes a lot of coding and bit flipping wizardry to create one that is: accurate, stable and fast. Nowadays they have math packages and libs you can simply load and call, but for most of Apple II's life, there never was anything like that, meaning you pretty much had to roll your own. Nor did they have any sort of math coprocessor for it so the CPU (6502) had to do it all.
Even Steve Wozniak was asked several times by Jobs to create a floating point version of his Integer BASIC, but Wozniak never did. Jobs had to resort to paying Bill Gates and a team of engineers a lot of money to write Applesoft BASIC for him. Wozniak said the scope of doing that was beyond his attention span (which he approximated as more than a month). I mean, this guy built Apple II's disk interface AND the disk operating system in about a week. So he could have written a FP version of BASiC, but he figured it would take longer than his liking.
How do I know? Because I asked him. In my freshman year in college, I had to write a 6502 emulator, which itself is not hard except I was given limited cycles for the instruction codes and I had to match the clock speed on the Apple II they had in the labs for us to take apart. Wozniak, being a friend of the prof, suddenly appeared one day to do an impromptu AMA session for 30 min. By this time, I had the emulator pretty much finished and was looking to emulate the rest of the Apple II.
That's why I'm kinda fond of the 6502 cpu, or rather the Apple II. So, just out of curiosity, I'd like to know how you did the things you keep claiming. I'm not asking you to produce the machine language math code, since I have my own... somewhere I think on my NAS. I'm just asking how you approached such a project, and just tell us even in theory how you manage to create something that eluded even Wozniak -- bona fide genius by the way, even if a bit impatient.
edit: added spacing to questions to make them clearer
Comments
That’s the whole point of firmware updates. It’s beyond obvious that there could have been at least a couple of years of firmware updates and at least a couple of years of actual usage, but instead, as has been said before by others, we have an endless feature creep, optimisation process, ageing Li-Ion batteries and more.
The ability of Mark and his investors to keep shovelling money into a company producing no returns and potentially ever fewer pre-orders is also in continual question for customers.
That concern prompted me to cancel, despite my still wanting a TextBlade, and despite the “free gift” causing me to hold off.
In the end no free gift was worth the worry that Waytools would go by the wayside, I didn’t order a TextBlade to get a free gift, I ordered a TextBlade to get a TextBlade.
I ended up cancelling, which allows Mark to gleefully point out that I am “no longer a customer” and allows him to question whether I am a secret agent from Logitech looking to besmirch and destroy Waytools and Mark’s reputation.
Sadly for Mark he is doing that all by himself. 800+ posts because Mark can only communicate in anger, and in conspiracy talk etc etc etc etc.
As Rolanbek so wisely stated, all some of us ever wanted was a small keyboard.
There are great questions and observations from a range of commenters above.
Sadly we know Mark will ignore 99.9% of those, will find a word or two to get outraged about, will throw an insult or two here or there, will remind some of that that we’re not even customers, and well, we all know the drill, only too well.
The only surprise left in Mark’s arsenal beyond bad ones of further delays is general release, or GR.
Otherwise that’s it, we’re stuck in one of Dr Strange’s time loops, and we can all come back here in 2020, 2021 and just end up in a Catch 2022 situation.
I’d ask Mark to prove us wrong, but I already did, and he didn’t.
Mark, don’t bother responding, any of us here can copy and paste one of your previous responses.
I might start doing doing that in future to predict what you might say and to save you the time so you use that time in the evenings to live life, sleep, or do something more productive.
We have 4+ years of Waytools_Support responses to copy and paste from.
Here’s one I took a few seconds to piece together.
You’ve always controlled your money. Just push the button and take it back if you don’t believe in our good faith.
Since you’re still engaged on topic, we hope that you’ll ultimately have a good experience with a unit, and are very happy.
Hopefully you’ll quite like it when you can try a TextBlade for yourself. Thanks.
We didn’t initiate, we only responded.
It would be really nice for everyone if there we’re (sic) no attacks to answer.
etc etc, dum spiro spero, docendo discimus, eheu fugaces labuntur anni, 仕事に戻る, et cetera
Even when the feature looks like it's been implemented successfully, you still have to test it anew internally. And then check for interactions with any other new code you've written. And then push a new build. And then stress test it externally. And, as they've said, the design and UI of it needs to be carefully crafted to begin with, and that takes time too. Etc. Etc.
In any project, it always seems like it'll be so simple. "What could possibly go wrong?"
I don't know any competent software project manager who thinks that you can add features (no matter how small) without extending the deadline. Hard-won experience from every PM is that the only way to stop the cycle to is to do a for-real feature-freeze and not be wishy-washy about it.
But more realistically, in a project this size, code_block_B is fine with it, but code_block_C depends on B, and D depends on C and...Z depends on Y, and it is code_block_Z that expects code_block_A to work the old way and throws a bug.
And then 1 out of a hundred testers trips over this bug, but it is nearly impossible to reproduce. But WayTools cares very much about this level of quality, so they can't just let it slide. And they can't just revert the code, because now code_block_J and code_block_Q rely on code_block_A working the *new* way. So it takes weeks to find a way to reliably reproduce the bug, and more time to fix it, and then more time to test it, which uncovers more edge cases, which requires weeks to reliably reproduce the bug, which requires...
1. It seems reasonable to say that it is only the present firmware that we have in Treg that WT has considered to be "good enough". At least they never said that about any other version.
2. That being the case, and since that version came out in, I think, September, that would be the earliest they could have shipped. But even that wouldn't be true since they couldn't know it would pass their standards until after it had passed enough of their own and enough Treg testing to confirm they had achieved that goal. I don't think there is any chance that could take less than a month no matter how good the testing was over the first 2-3 weeks. Because they have surely learned that problems have popped up many times before. So that moves us to sometime in October, AT BEST. The point here is that we wouldn't have had it for years, but 7 months at best and maybe much less! I've seen plenty of people declare it would take at least 6 months of such testing, so that would mean it would only be released 2 months ago! Just narrowing down the areas to complain about
3. But by then they also knew they had a huge problem with space. No matter how good testing turned out, sending it out to tens or even hundreds of thousands of customers, issues are going to show up!
It is, in my opinion, we get to the question of what they should have done. I also submit there is no "right" answer as both involve big risks to the company. In short, do they ship and let people suffer with issues they can't fix readily because of the need to rewrite not only the "bug" part, but other things to make room for the fix, or do they free up the space first by rewriting and testing.
The first gets it out the door and makes many people happy. But it may also make a lot of people unhappy because of issues a rewrite would eliminate or minimize.
The second makes people who are tired of waiting even angrier. But, to be honest, most people who ordered probably aren't even thinking about it - may have even forgotten about it. So the people becoming angrier are going to be a fairly consistent number who were also angry years ago. So, as a BUSINESS decision, the greater risk may well be viewed as having a lot of customers complaining about some problem they run into and WT not being able to deal with the problems quickly.
And remember, a lot of these "problems" are really going to be user error. I can't emphasize that enough, but because of how it works, they ARE going to think it is the product rather than themselves. So they'll have a base percentage of user support demands that aren't the fault of WT. The more they can limit those issues that ARE something they can fix ahead of time, the better.
Add in the slowdown in development of the new firmware if they are also actively trying to rewrite, piecemeal, the firmware any time a new issue is reported and you have a real mess.
To me it isn't about which approach they SHOULD do because, as I said, I don't think there is a definitive "right" answer. To me it is about whether the decision they make seems to make sense and I think it does. But if they said they decided to ship today, I'd be fine with that too.
But let's say it isn't. Think about what that means if they didn't do the rewrite! Most fixes will tend to take more memory, forcing a rewrite of unrelated items. And so every time one thing has to be fixed, you are not only risking things from the change to fix the bug but another change to make room! It could require even more than one other change, but regardless, you are doubling, or more, the chances of creating a new issue.
Imagine for a moment, actually working for Mark Knighton as a software developer. Consider the way he communicates, and then imagine working under someone like that. He has probably gone through at least 2 or 3 developers since the inception of this project and driven a couple of poor bastards insane in the process. He probably kept asking the developers to add more and more and more features, year after year, until one finally snapped, fired up 'Take This Job and Shove It' by Johnny Paycheck on Youtube, set the volume to 11, and screamed at him 'It is full !!!! Nothing and I mean nothing else is going to fit in your 5 year old hardware!! I quit!' and stormed out of the building to find a new less stressful career, like gathering acorns for disabled chipmunks in the forest.
https://forums.macrumors.com/threads/hands-on-with-the-collapsible-magnetic-textblade-keyboard-for-ios-devices.1852755/page-10#post-20836342
It's definitely in the same voice as Waytools_Support. It shows the kind of inanity we see from Waytools_Suppport was there from the beginning.
The attempt at an "I am Iron Man" ending is funny.
Given my penchant for rewrites, it should be rewritten:
"My name is Mark Knighton, and I run WayTools into the ground".
Original is below. The voice is unmistakably Waytools_Support, and remember, this post from March 13, 2015, is essentially the same post Mark has rewritten hundreds or even thousands of times since, and we see the seeds of Oppo-PR paranoia being sown below. As with so much about Waytools, it is absolutely astonishing.
Let us also remember Mark's first sentence below, and rewrite it again: "The magnificence of the internet is that it gives everyone a voice. That is why we have the Waytools Forum, where we can silence the voices of those we don't like - at will. You have been warned, shadow banning is what we do."
As one who was unjustly shadow banned, I know from personal experience.
+++
Even the quieter voices can out the truths that deserve to be heard.
With this freedom and power, also comes hazard. Anyone can claim anything, without any evidence. Even diametrically untrue things, carefully contrived for commercial interest.
They can do all of this anonymously, with an artificial persona, and no real identity at all. This new reality requires that we discern for ourselves what we consider to be credible.
A few personal observations based on logic -
A company that gives customers direct control over refunds at all times, does not suggest dishonesty.
A customer who is not pleased, cancels. They generally don't spend their time writing public diatribes misrepresenting dates and communications. (like this).
A poster who cites unrelated horror stories, and then knits them to their target, has a purpose in mind.
And, unfortunately, established players worried about a disruptive technology, really do pay operatives to discredit a promising change.
I think consumers would prefer to see effort go instead toward making great products.
My name is Mark Knighton, and I run WayTools.
I argued that their estimate-making process was broken since it always outputted "next [time period]" even if the input was something along the lines of "we just discovered a hardware issue that requires a serious overhaul and redesign of the butterfly switches". Somehow you interpreted that as me arguing that they should make less *frequent* estimates instead of a call for an overhaul of how they make their estimates in the first place.
This is mindboggling and ironic since this was originally one of my complaints on the WayTools Forum--which was that no amount of firmware improvements will solve user error. Somehow you've managed to twist it backwards into a rationale that essentially demands perfection (even though you and WayTools have explicitly said that they are not demanding perfection). With this thinking, no matter what, it is always justified to delay for improvements for the sake of people who will blame WayTools for their own errors regardless.
They say they don't require perfection to ship, but every visible action and all of their other stated rationales that I've seen indicate that they think otherwise. And all of your statements indicate that while you would be happy for them to ship now, you are also fine with them delaying any amount of time to reach any arbitrarily high level of quality that they are satisfied with (i.e. perfect in all but name).
Well that's the thing, *all sorts of things* can be justified as BUSINESS decisions, especially unethical ones. When we complain about what they SHOULD do, that generally implies ethics, not business. Of course there is overlap, but just saying that X decision "seems to make sense" from a business standpoint makes for a crummy ethical stance.
"My name is Mark Knighton, and I run WayTools."
I can totally hear that in RDJ's voice.
I don’t hear RDJ’s voice. I hear Thanos, or some other villain. Mark “Khaleesi S08E05” Knighton is definitely not my hero, but a great example of how not to run a business, how not to do PR, how not to do customer support, how not to live life and how not to be a person or a man, and how not to smugly read this and still think with a smirk he’s heroic TextBladeMan.
Mark is a great example of how to be consistent though, as you point out. There’s always a silver lining somewhere, if you stretch hard enough to find the needle of good in the haystack of indifference.
For all we know, these were the only code edit they made in several months:
"We made great strides, doing complete rewrite, adding advanced features. We worked hard burning the midnight oil for months. We think you'll like it!" -- Waytools (err, Mark Knighton)
For all we know, the current Textblade hardware may be comprised of old 6502 CPUs cobbled together from recycled VIC-20s, and the code is written in Microsoft BASIC. Anything is possible.
gosub line # .... lolz. Brings back memories from my pre-teen years when I was doing the same thing that Kahuna often proudly claims as his primary programming experience. Typing code from Compute!'s Gazette magazine into a Commodore 64. That was around 1983 I think. Then I moved on to Apple and Pascal.
Then there is the matter that when rewriting, they are obviously going to be not only compacting the code, but in some cases this will require different structures to save more space, which opens up other opportunities. Back to jumps, they may have had to restructure them - which would also allow more of them automatically, which they couldn't do before the restructure. I would think it would be foolish of them to say, "Let's rewrite it to save a little memory, but not as much as to change the structure which will save LOTS of memory - and which would also have the bonus of allowing more jumps". To me it would be logical to change the structure even if it also allowed jumps to exceed "parity".
> This is why I was insisting years ago that their estimate of "this month" (for any given month when they said it) was unrealistic (especially when it was the last week of that month)
> This is mindboggling and ironic since this was originally one of my complaints on the WayTools Forum--which was that no amount of firmware improvements will solve user error. Somehow you've managed to twist it backwards into a rationale that essentially demands perfection (even though you and WayTools have explicitly said that they are not demanding perfection). With this thinking, no matter what, it is always justified to delay for improvements for the sake of people who will blame WayTools for their own errors regardless.
1. We can handle X number of customer support issues a day.
2. We can expert Y number (less than X) will be simple user error.
3. We anticipate Z number of problems based on current firmware (let's say in 2017).
4. Y + Z is greater than X. So they have to work to reduce Z. But not to zero (perfection). But enough so Y+Z is no more than X.
> They say they don't require perfection to ship, but every visible action and all of their other stated rationales that I've seen indicate that they think otherwise.
> Well that's the thing, *all sorts of things* can be justified as BUSINESS decisions, especially unethical ones. When we complain about what they SHOULD do, that generally implies ethics, not business.
A feature freeze actually is a rock solid concept. There are different degrees of freeze implemented at various stages of any successfully managed software project.
As is obvious to all, both you and Waytools (Mark Knighton) have no idea how to go about managing development, hence the absurd 4+ years of consecutive delays.
Kahuna, are you the software team leader on the Textblade project?
But what I mostly did - and have posted about - is write in BASIC AND machine code for the best mesh of each (BASIC being simpler/quicker to do, but machine code being faster and often requiring less memory.
It was really quite effective. Using a BASIC line for "Input name" is close enough to doing the same thing with machine code. But machine code paid off in a big way when sorting or calculating, etc. Even had a few full time programmers ask to use some things I worked out.
I can certainly tell you what they did and contrast with what I saw available on Apple II series of computers at the time (hint: Mine were faster, held more data, and structured into a more useful form on screen).
Ah yes, this reminds of the discussion you and I had many moons ago.
You never did answer my questions about how you accomplished the things you claim. Just to be sure, you're claiming you wrote some grading program (a mix of BASIC + machine language code) on your Apple II that did some math for you (IIRC).
My questions were:
The reason why I ask the last one is because doing decimal math via binary is not for the faint of heart. It takes a lot of coding and bit flipping wizardry to create one that is: accurate, stable and fast. Nowadays they have math packages and libs you can simply load and call, but for most of Apple II's life, there never was anything like that, meaning you pretty much had to roll your own. Nor did they have any sort of math coprocessor for it so the CPU (6502) had to do it all.
Even Steve Wozniak was asked several times by Jobs to create a floating point version of his Integer BASIC, but Wozniak never did. Jobs had to resort to paying Bill Gates and a team of engineers a lot of money to write Applesoft BASIC for him. Wozniak said the scope of doing that was beyond his attention span (which he approximated as more than a month). I mean, this guy built Apple II's disk interface AND the disk operating system in about a week. So he could have written a FP version of BASiC, but he figured it would take longer than his liking.
How do I know? Because I asked him. In my freshman year in college, I had to write a 6502 emulator, which itself is not hard except I was given limited cycles for the instruction codes and I had to match the clock speed on the Apple II they had in the labs for us to take apart. Wozniak, being a friend of the prof, suddenly appeared one day to do an impromptu AMA session for 30 min. By this time, I had the emulator pretty much finished and was looking to emulate the rest of the Apple II.
That's why I'm kinda fond of the 6502 cpu, or rather the Apple II. So, just out of curiosity, I'd like to know how you did the things you keep claiming. I'm not asking you to produce the machine language math code, since I have my own... somewhere I think on my NAS. I'm just asking how you approached such a project, and just tell us even in theory how you manage to create something that eluded even Wozniak -- bona fide genius by the way, even if a bit impatient.
edit: added spacing to questions to make them clearer