I have lots of language references -- SNOBOL, MUMPS, LISP (et al.), Limbo,
PL/1, Modula2, Ada, C, C++, tcl, FORTRAN, Icon, etc. I spent a fair bit of
time surveying them when I designed the scripting language for this project.
If users can be blind, mobility impaired, etc. then surely the scripting
language should address those same issues! Look at your code and imagine
how a blind person would "view" it (spoken or braille). Or, how many
keys a physically disabled person would have to hunt-and-peck to
create/edit it. *Then*, think about how they would "do stuff" with it...
I originally tried to wrap my objects in C++ wrappers. But, found it
only made things harder to understand.
E.g., a "handle" for an object isn't a pointer. There's no way to dereference
it in any language. Nor is it possible to determine if two object handles
reference the same "physical" object (a handle also includes access
capabilities so you might be able to perform operations A and B on an object
through *this* handle; but C and D on the same object through THAT handle).
Where I really miss the C++ notational syntax ("sugar") is for mathematical
operations with nonstandard data types. E.g., in my scripting language,
everything is a BigRational. It would be *much* nicer to be able to say:
BigRational Amps, Volts, Resistance;
Amps = Volts / Resistance;
than to have to introduce function calls for each operator.
I like long, descriptive names. E.g., divisor, dividend, quotient.
"a" and "b" just don't cut it. Even iterators get names instead of
generic i, j, k. I think row++ means more than i++ or even r++.
You only have to type the identifiers when you're writing the code;
they don't influence performance.
I want to be able to subvocalize as I'm reading the code; so, "row++"
is "next row" whereas "i++" would be...?
This is important when "reading" code to a blind user -- how would you
When you think about what technology (hardware and software) was like
40+ years ago, it's a wonder ANYTHING worked! Far more "art" than "science"
I looked at Ada as an option to enhance robustness. But, came away with
the impression that "discipline" is just as good. Ada just tries to
I don't like anything "proprietary". I want to be able to move to
a different processor in a heartbeat -- and not have to worry that
my code is not portable.
This even extends to compiler pragmas, data types, etc. "unit16_t" not
"short". I routinely test how well I'm doing by running my code through
a variety of compilers (gcc, borland and sun's). I have test suites so
I can look at the results and wonder why something isn't as I'd expect
and then tweek the code accordingly.
I still use i although the array or whatever I'm iterating gets a
descriptive name. We had one programmer who thought anything more that
ary was too much typing. There can be too much of a good thing though:
The deeper you get into gtk the longer the function names get. And they
all start with gtk_. It was an admirable effort not to pollute the
namespace just in case some else had a toggle_button_set_state() but
even tab completion gets tedious.
It depends on what that array/structure references.
E.g., if I have a bag of items, then it might be "count". Or, if
it is a list of people, it might be "person". etc.
Yes. One other "loss" by not using C++ was the support for namespaces.
I had asked "others" for details about which C++ features dragged in
"unseen overhead" in the hope of being able to use just those features
without the "invisible other cruft" (default constructors, RTTI, exceptions,
etc.). But, noticed folks (who were normally quick to offer "opinions")
were awfully silent or tentative in their answers. I figured something
that fundamental SHOULD have a simple, obvious answer and the fact that
it couldn't produce one (that would apply regardless of compiler choice)
was an "early warning" that surprises lie ahead!
The one thing I like which eventually made it into the language via the
STL are containers. Those were offset by the whole iostream fiasco which
I consider to be complex, confusing, and inefficient.
My problem is I can see through the syntactic sugar. try/catch is clean
and elegant but if there isn't one of Djikstra's dreaded goto's lurking
in there I'll eat it. That's after you punch through a few vtables to
figure out where you're going to.
Lambdas also seemed much ado about nothing but it's getting so no
language has arrived unless it has lambdas.
Containers were never a problem for me; I'm a big fan of pointers so
handling containers of any "type" was just a matter of juggling
lists of pointers. I rely on "hacks" under C to give me features
that I want typically by exploiting pointers. E.g., I use the
"object->method" syntax by converting my "handles" into struct
instances (more like C with classes). This highlights the relationship
of "method" to "object" as well as helping out with the namespace issue
(e.g., each object has a "constructor" of sorts so I want a "new" method
to let me instantiate another similar -- or identical -- object based on
the object I have in my hand, at the time)
This is the heart of the problem C++ poses for me over C; I can *see* what
C will be doing and get a good feel for how many opcodes will be required
(for a given processor). As you add all the behind the scenes magic in
C++, things get a bit murkier: *where* are those opcode fetches going
to occur? will they result in cache misses? what about the pointers
that it will be chasing down -- how much time repriming the cache... JUST
for that one object in this expression!
Years ago, with smaller (embedded) processors, you didn't worry about this
cuz there wasn't much of "acceleration" built into the processor. Now,
though, even small caches are commonplace and can make a noticeable
difference in performance. Silly to throw that away due to poor locality
And everyone wants to come up with their own extensions to these (along with
everything else in the language).
There is a point where a language gets too damn complex and ambiguous.
Why not program in *English*? That's wonderfully UNambiguous (NOT!), right?
The more complex the language, the fewer "expert" practitioners. And,
the greater the tendency towards zealotry: people have INVESTED a lot
and feel some need to JUSTIFY that investment -- the language (or any
other technology) colors their future decisions in ways of which that
they might not be aware. (hammer, nail)
A "project" can be "too complex" -- and a *solution* can be too complex!
Complexity wins only when it can be hidden. If you have to be aware of
the complexity FOR ANY REASON then it starts to become counterproductive.
My RTOS's API is pretty fat. Fat suggests complex. But, much of my complexity
manifests in very consistent ways -- i.e., a common set of arguments for
most function calls (instead of special function calls for different sets
of arguments). A bit more typing "at development time" but a lot less
to have to remember (special cases, etc.).
[One of the features of C++ that I did NOT like was "optional, *default*
arguments"; too easy to forget they are there and lose out on the
functionality they provide!]
Sunday lunch -- finestkind!
Yes. In my case, (running NetBSD), I install the "pkgsrc" collection
which provides a mechanism for me to build the programs that I want,
the *way* I want them built.
[Most folks would opt for the prebuilt varieties but I like to
tweek mine to suit *my* needs -- not the needs that some faceless
developer thought would be important. Additionally, I want to
*watch* the build process to be sure there are NO errors or
serious warnings -- that the faceless developer may have glossed
over. This is necessary because the sources may have been written
with a particular build environment in mind that is different
from the current one!]
But, I tend to want very few things that aren't part of the "stock"
system -- maybe a few little tools to make using the window environment
a bit easier (but *no* desktop, "office suite", etc.). The "most involved"
application that I use would be PostgreSQL (a relational database
program) and the folks who maintain it are *really* professional
and treat it almost as a *job*!
Yes. You're "stuck" with whatever some other developer happened to have
on hand and opted to "make work". And, only as well *as* he made it
work! I.e., often, certain features are unsupported. Perhaps some
of those extra buttons, or maybe the ability to DYNAMICALLY vary the
sensitivity with a control ON the mouse (instead of having to open some
"control panel" to do so)
In my case, I only talk to other computers, storage devices and generic
printers (e.g., laserjets). All things that I long ago sorted out how to
*make* work -- and I just keep carrying those configuration files
forward each time I "upgrade" the OS.
Anything "interesting", here, is connected to a Windows machine. This is
because the folks who sold those things wanted to target the largest
possible audience! Many of them I *could* make work (or write a driver/filter
if that was needed) but the APPLICATIONS for which they are useful are
missing -- so, what's the point? (e.g., I could write an interface
for my motion controller; but where's the 3D CAD program to take advantage
of that to manipulate 3D models in real time?)
Again, you have to approach the problem from the top, down:
You make a list of the capabilities that you want (i.e., to
write letters, balance checkbook, design microwave cavities,
Then, you list the possible applications that can provide each of
Then, list the operating systems that will support each of those
Then, try to find the sweet spot that supports the greatest number of
the most valuable applications -- expecting to NOT have some of the
things that you "want".
If your best case isn't good enough, then you can't pursue that OS!
[Note this ignores issues like *cost*!]
In my case, I have a Windows machine that hosts all of my publishing
tools and related peripherals. Another Windows machine for my EDA tools
(and THOSE peripherals). And a third for my multimedia authoring tools.
*This* (Windows) machine handles email/WWW.
All of my software development and testing is done on Solaris/SPARC
machines (especially helpful as it uses a different byte ordering
so I can stress some of the portability issues in my code) and NetBSD
machines (Intel/AMD based). The Windows tools are just not generic
enough to write portable code.
No. All of the pieces were developed independently of each other.
They weren't designed to "play nice" together but, rather, just to
address some particular need.
Every program has a different set of "command line options". Each
has its own unique "configuration file format". They can't even
agree on some of the "basics" in all of these things!
E.g., most programs allow whitespace in configuration files. Many
treat spaces and tabs as whitespace; some will include newlines, as
well! Others will ONLY accept tabs. Or spaces. Some will allow
you to inject comments into the configuration file by preceding
the comment with a semicolon. Others, a "hash # mark". Still others,
an exclamation point! Some recognize C or C++ style "comments".
And, virtually all of them will complain if you try to insert a
"comment" in a form that is not supported. So, how can you come
up with a common "configuration interface" (dialog boxes?) if the
files that it must manipulate have such varied formats/syntax?
[Ans: you have to start over from scratch and come up with a consistent
way of addressing *all* such configuration information. Then, back
port this into all of those existing programs -- replacing the code
they have written to parse their individual configuration files
with some code that knows how to deal with this new "universal form"]
But folks take different approaches to any particular problem. E.g.,
the Internet Super Daemon (inetd) is implemented differently in
the Linux world vs. the *BSD world. Some implementations of some
tools might have bugs that have been fixed in others. A lot of effort
goes into making sure a particular set of libraries OR another,
different, set of libraries can be used to support the implementation.
And, address architectures that have different byte orderings,
structure packing rules, floating point formats, etc.
Windows sidesteps these problems -- until recently, it was a 32b
environment running on Intel! (the sources for NetBSD run on some
~60 hardware platforms across 15 different processor architectures,
"out of the box"!)
One of Linux's problems is they change the kernel too often. It
would be like saying your application requires Windows 7.20336
(and the various other things that accompany that). A vendor
doesn't want to be a flea on the dail of a dog that can't stop
wagging! The *vendor's* costs skyrocket!
But, the Linux folks have this mantra about always wanting to tweek
every little thing -- endlessly. If it was a car, you'd ALWAYS be
"in the shop". AND, they'd be EXCITED to tell you about how GREAT this
latest modification is going to be! "You'll LOVE it!"
("But, I just want to go to buy my groceries; I don't care if the
turbocharger now gets an extra 0.3 MPG for the same output!")
Exactly. You NEVER have to *produce*! "Shoot the Engineer"
To be fair, imagine creating a (ham) transceiver IN YOUR SPARE TIME
(not "compensated" financially). How much effort would you put
into a nice case, fancy knobs/dials, a detailed manual, ease of
use, a consistent interface with the "other" ham kit hobbyists are
producing (power switch located in the same general location, power
indicator a particular shade of red, inputs on the left, outputs on
the right, etc.), etc.?
Or, would you just opt for an expedient -- something that YOU
(and folks like you with whom you'll share the plans) can have
up and running later this week?
When someone following after you had problems recreating your work, would
you immediately slip into technical jargon (after all, they SHOULD know
this stuff if they're aiming to build a rig!)? Or, would you adjust
your comments to their actual skill level -- only to discover they don't
even know to plug in the soldering iron?
Would you then monitor comments others had about your design (parts not
derated aggressively enough) and tweak the design to reflect those
improvements? For the next few months? Few years?? Decade??? (some
pieces of software ARE that old!) Or, would you much rather move on to
that new automatic keyer you've been thinking about designing? After
all, this was just a hobby project in YOUR mind...
Some things are much better on Linux.
I have a Canon camera I bought in 2008. It has a USB port, but doesn't
do anything on a Windows system unless I install the complex bloated
software which came with it. The software didn't work right so I just
used a SD card reader to transfer images. Laptops usually have those
When I got Linux I just plugged the camera in and the camera appears as
a drive. Just what I want.
All you need is the .inf file that declares the Vendor ID (VID) and Product
ID (PID) values for that specific "device". You can extract them from your
Linux system (lsusb(8)) and fabricate a suitable .INF file (or, hack
the registry manually).
Thereafter, when that VID/PID is encountered, Windows will automatically
install the device as a "mass storage (disk)" device.
[I've done this in the past with PMP's that insisted on being accessed
via some third party app]
Where the free Eunices usually excel is with network and other services
(that are usually an afterthought to MS -- or, that MS wants to "reinvent"
in a proprietary way)
I've had 3 Canon cameras on Slackware Linux. Sometimes gotta use a
card reader. Other times, jes plug into camera and use gphoto2
(digikam GUI). I've never used Canon's software, mainly cuz Canon is
notorious amongst Linux users as being painfully anti-Linux, so they
never provide their software ported to that OS. Gotta find another
Still, there's usually some way. ;)
What I find amusing in the Linux camp is their expectation that they are
somehow ENTITLED to having access to this proprietary/trade secret
information that is an inherent part of the vendor's IP.
If a vendor wants to share its software with a *portion* of its
user base, then more power to them. But, thinking that the
user SHOULD share it is awfully presumptuous.
Does your employer think you should (freely) SHARE your expertise
with him? Why do you insist on being paid for it? Think of the
Greater Good that would come from your sharing it freely -- your
employer could then share its PRODUCTS more freely -- everyone wins!
(not! :> )
If its important enough to you, you;ll chose a product from another vendor;
one who's products "play nicely" with your tools. Of course, if that
product doesn't have the features/quality that you want... <shrug>. The
*masses* limit your choices to what THEY want (i.e., are willing to pay for).
That's been my approach. I don't know if they've gotten better but
Lexmark printers were much happier married to a Windows box. Hence I've
got a Samsung laser printer that installed with no fuss. Back in the
modem days, the WinModems used Windows to do the heavy lifting so I
bought real modems. Brand X laptop doesn't do Linux; there are other
fish in the sea. ATI drivers are iffy? Nvidia works for me.
I'm not a Stallman purist that shudders at the thought of proprietary
drivers but I support the manufacturers that support Linux.
I'm not a zealot nor an evangelist. If it works for me (whatever "it" is),
that's fine. If it works for you, that's great, too! If it doesn't,
<shrug> -- no skin off my back!
I figure people/companies are entitled to make money off their labors.
I don't hear many folks advocating PC vendors GIVE AWAY PC's! Nor do
I see accountants working for free, etc. (the same accountants who might
be advocating for "free software")
Stallman is largely irrelevant. He can be replaced by an an automaton as his
answers to all questions boil down to "use the source" or "make the source
Early on in the design of my automation system, I talked to a bunch of
people about the privacy issues involved. Specifically, how to give the
user some control over what information is disclosed -- intentionally
or indirectly -- by the system in its normal operation.
[This is roughly equivalent to asking how to give cell phone owners
some control over what information "apps" can disclose without their
consent/knowledge -- each app is a black box to the user! Or, can
"rationalize" why it needs access to some particular bit of information]
His answer was "give them the sources". WTF? How does having the source
code for the system (or, an app on your cell phone!) help Grandma decide
what information she wants to allow out? Does he really think everyone is
a programmer? Or, that folks are going to rush out and HIRE programmers
to "enforce their privacy constraints"??
Something about "hammer" and "nail" comes to mind...
To anyone who might know the answer to my question...
After reading this thread about MS trying to force installation of
Windows 10, I turned off my automatic windows update yesterday, and
thumbed through the past updates out of curiosity. I noticed multiple
times in the fall of 2015 where MS tried to download and install Win10
and it said all attempts have failed. I'm glad they failed, and it may
be because I changed some setting a while back (that I can't remember
specifically what it was).
My question is since I've now turned off auto updates, how often should
I check for updates that I may actually need to allow to be downloaded,
and will it say "Win10" in the list to I know to reject that d/l?
Tuesday is when the newest set of patches are RELEASED.
There are millions of Windows machines out there. If
they all opted to contact MS's update servers on Tuesday,
no one would ever get any updates!
| My question is since I've now turned off auto updates, how often should
| I check for updates that I may actually need to allow to be downloaded,
| and will it say "Win10" in the list to I know to reject that d/l?
How often is up to you. MS is specifically
saying that they're not going to detail patches
anymore, so online gossip may be your only guide.
I never allow WU. With XP I stick with SP3. With
Win7 I stick with SP1. The vast majority of security
fixes are not really for Windows but rather for
software: Internet Explorer, MS Office, etc.
There are people who will disagree and think it's
very important to get all updates. I regard that as
a blind "new is better" approach. However you
decide to deal with it yourself, it's likely that
you'll need to oversee updates very closely if you
want to avoid spyware, Windows 10, and whatever
else they decide to foist on Win7.
HomeOwnersHub.com is a website for homeowners and building and maintenance pros. It is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.