 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/19/2011 8:33, clipka wrote:
> Most bloody likely not.
*Essentially*. Of course all the floors aren't built quite the same, but
they're all variations on the theme. They're each a mostly a subroutine
invoked with varying parameters, rather than being designed from scratch
each time.
Or, put it another way: You build a housing development with 400 homes. How
many of those do you build from scratch, vs how many do you effortlessly
copy after you've built the first one?
There's an *essential* complexity to software that you don't get from
hardware, because there's no such thing as a subroutine outside of the world
of information.
--
Darren New, San Diego CA, USA (PST)
How come I never get only one kudo?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 19.08.2011 17:45, schrieb Darren New:
> On 8/19/2011 8:33, clipka wrote:
>> Most bloody likely not.
>
> *Essentially*. Of course all the floors aren't built quite the same, but
> they're all variations on the theme. They're each a mostly a subroutine
> invoked with varying parameters, rather than being designed from scratch
> each time.
>
> Or, put it another way: You build a housing development with 400 homes.
> How many of those do you build from scratch, vs how many do you
> effortlessly copy after you've built the first one?
>
> There's an *essential* complexity to software that you don't get from
> hardware, because there's no such thing as a subroutine outside of the
> world of information.
It makes more sense to think of a piece of Software as a mold, or a
blueprint.
In that sense, you can compare subroutines to parts (or, more precisely,
part types); for instance, a mechanical device optimized for
maintainability would use just one or two types of screws everywhere.
And the crew aboard spacecraft Apollo 13 would have had one problem less
if the Command Module and Lunar Module would have used the same
"subroutine" (i.e. same design) for the CO2 filters, but for some reason
the "functionality" was "implemented" twice, using different "interfaces".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/19/2011 9:40, clipka wrote:
> It makes more sense to think of a piece of Software as a mold, or a blueprint.
Exactly. Software is 100% design. Once you have determined *exactly* what
you want to build, you're already done. :-)
--
Darren New, San Diego CA, USA (PST)
How come I never get only one kudo?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 19.08.2011 19:22, schrieb Darren New:
> On 8/19/2011 9:40, clipka wrote:
>> It makes more sense to think of a piece of Software as a mold, or a
>> blueprint.
>
> Exactly. Software is 100% design. Once you have determined *exactly*
> what you want to build, you're already done. :-)
Well, not precisely - you still have to translate the design of what you
want to build into a computer-palatable language. And it so happens that
often you find out during this phase that you weren't clear about what
*exactly* you wanted to build.
That aside, IT as a whole is about much more than just design; once you
have the software, you need to test it, install it, teach people to use
it, and other less exciting stuff. Sometimes business people forget
about these things. It's like they pay an architect to design a new
building for them, but forget the budget to actually build that thing
(let alone to move from the old building to the new one).
But hey, they also seem to forget about all this stuff when it comes to
company mergers. Yeah, sure, in the long run you may indeed get "synergy
effects", but until then you're in for a lot of organizational overhead
minimizing your productivity. And once you're breaking even you're
possibly doing the next merger already.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/19/2011 15:05, clipka wrote:
> Well, not precisely - you still have to translate the design of what you
> want to build into a computer-palatable language. And it so happens that
> often you find out during this phase that you weren't clear about what
> *exactly* you wanted to build.
That's part of being sufficiently exact. If you're sufficiently exact, the
translation step can be automated. (For example, we call that "a compiler". ;-)
> That aside, IT as a whole is about much more than just design; once you have
> the software, you need to test it, install it, teach people to use it, and
> other less exciting stuff.
There is that. Altho I'd classify testing it (in terms of "does this meet
the spec" and not in terms of "do the users like what we spec'ed enough to
pay us") as part of the design. It's ensuring the design is right.
> doing the next merger already.
Heh.
--
Darren New, San Diego CA, USA (PST)
How come I never get only one kudo?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 20/08/2011 01:31 AM, Darren New wrote:
> On 8/19/2011 15:05, clipka wrote:
>> Well, not precisely - you still have to translate the design of what you
>> want to build into a computer-palatable language. And it so happens that
>> often you find out during this phase that you weren't clear about what
>> *exactly* you wanted to build.
>
> That's part of being sufficiently exact. If you're sufficiently exact,
> the translation step can be automated. (For example, we call that "a
> compiler". ;-)
Lest anyone doubt this, at uni we learned about something called
Computer Aided Software Engineering ("CASE"). We used a tool called
Rational Rose. You draw various class diagrams, flowcharts, etc., and
then press a button, and it spits out C++ source code. If your diagrams
are detailed enough, the generated code actually compiles and runs, and
*is* "the finished system".
All without you ever writing a single line of code yourself. Or even
knowing *how* to program C++.
So yes, if your design is detailed enough, the translation is (or can be
made) automatic.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 20.08.2011 11:49, schrieb Orchid XP v8:
> Lest anyone doubt this, at uni we learned about something called
> Computer Aided Software Engineering ("CASE"). We used a tool called
> Rational Rose. You draw various class diagrams, flowcharts, etc., and
> then press a button, and it spits out C++ source code. If your diagrams
> are detailed enough, the generated code actually compiles and runs, and
> *is* "the finished system".
Similarly, Matlab/Simulink allows you to write your program by visually
"wiring" kind of "mathematic gates" (arithmetic ops, logical ops,
integrators, differentiators, level triggers, signal generators, signal
filters and what-have-you) and then have that translated to C and
ultimately machine code. Seen that recently hands-on in production use,
for the electronic controller of a car transmission.
> All without you ever writing a single line of code yourself. Or even
> knowing *how* to program C++.
>
> So yes, if your design is detailed enough, the translation is (or can be
> made) automatic.
... provided you trust the code generator.
Some portions of the car transmission software I mentioned were actually
still written directly in C; those were responsible for fail-safe
functions, so that even a bugs in the code generator couldn't possibly
cause an accident. (I'm not sure how they verified the C compilation
process though.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 20/08/2011 11:24 AM, clipka wrote:
> Am 20.08.2011 11:49, schrieb Orchid XP v8:
>> Lest anyone doubt this, at uni we learned about something called
>> Computer Aided Software Engineering ("CASE"). We used a tool called
>> Rational Rose. You draw various class diagrams, flowcharts, etc., and
>> then press a button, and it spits out C++ source code. If your diagrams
>> are detailed enough, the generated code actually compiles and runs, and
>> *is* "the finished system".
>
> Similarly, Matlab/Simulink allows you to write your program by visually
> "wiring" kind of "mathematic gates" (arithmetic ops, logical ops,
> integrators, differentiators, level triggers, signal generators, signal
> filters and what-have-you) and then have that translated to C and
> ultimately machine code. Seen that recently hands-on in production use,
> for the electronic controller of a car transmission.
Reaktor does the some thing with DSP. I can pick up a sawtooth
oscilator, a 2-poly LP filter, an ADSR envolope generator, hook them
together, and I've got a synthesizer. Not impressed? How about I hook
together a couple of 1-sample delay units, some (+) and (*) nodes, and
implement my 2-pole filter from first principles?
Other "module synthesizers" let you connect pre-built filters and so
forth together. Reaktor lets you design new ones from scratch, down to
the level of individual DSP algorithms. (On the other hand, it stupidly
lacks any kind of true subroutine capability, nor any looping constructs...)
>> All without you ever writing a single line of code yourself. Or even
>> knowing *how* to program C++.
>>
>> So yes, if your design is detailed enough, the translation is (or can be
>> made) automatic.
>
> ... provided you trust the code generator.
And the compiler. And the processor implementation. And, hell, the
entire hardware system you're going to run it on. And, if you want to be
picky about it, assuming your trust mankind's understandig of the laws
of physics...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/20/2011 3:24, clipka wrote:
> Similarly, Matlab/Simulink allows you to write your program by visually
> "wiring" kind of "mathematic gates"
Or VHDL, that lets you write the math for your hardware and have it generate
the hardware for you.
> accident. (I'm not sure how they verified the C compilation process though.)
At JPL, they disassemble the machine code and make sure it does what they
think the C said it does.
--
Darren New, San Diego CA, USA (PST)
How come I never get only one kudo?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 19-8-2011 15:21, Mike the Elder wrote:
> The REAL problem, as I see it, is the pig-headed unwillingness of so many
> corporate executives to employ people who actually KNOW whether $4,000.00
> software or $4,000,000.00 software is needed and allow them to make the purchase
> decisions.
This is mainly based on the idea that management is a skill in itself. A
manager of a workshop does not need to know anything about designing or
making things. Likewise, a manager of a hospital does not need to know
anything about medicine or patient care. Knowing management skills is
enough. Actually knowing what the people are doing will make it
impossible to judge objectively who is necessary and who can be fired.
Therefore the suggestion that you should be able to judge an IT contract
is an insult to management. Worse, people might use that to question the
level of salaries paid.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
