|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp escribió:
> I write too many commas, though. That's because I tend to instinctively
> put a comma everywhere where I would put it if I were writing in Finnish,
> where commas are used quote a lot. In English commas are used more rarely.
>
> I have lately tried to get rid of this instinct when writing in English.
>
I don't notice you using too many commas. A lot of German people do use
too many, though, and it gets annoying after a point...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gail Shaw wrote:
> I haven't looked too deeply, but it's on my list of languages to learn.
Speaking of functional, I think Andrew has mildly mischaracterised
Erlang as a functional language. While I've seen a few informal
references to needing to use a functional style to program Erlang, none
of the actual documentation says it's functional, and I never even saw a
mention of "referential transparency."
Indeed, I ran across this gem in the manual:
......
S = self(),
P = spawn(fun() -> do_something(S, 1, 2, 3) end).
...... (or some such)
along with the footnote that this isn't the same as
P = spawn(fun() -> do_something(self(), 1, 2, 3) end).
self() is the function that returns your current process id.
Spawn is the function that creates a new process to run the indicated
function. fun() -> ... end is lambda.
If you write the latter, the first argument is the process running the
function. If you write the former, the first argument is the parent
process (so to speak) that spawned the function and is likely expecting
some sort of message coming back when do_something() finishes.
Plus, there's a number of very explicitly statefull collections of data
in the system, including a hashtable for each process and a collection
of named hashtables for each OS-level process running an Erlang interpreter.
What they *do* say is that Erlang is a single-assignment language. Not
because it's "functional", but because it's easier to debug that way.
(Or so the research claims.) Me, I think I need to write a while()
function. :-)
--
Darren New / San Diego, CA, USA (PST)
"That's pretty. Where's that?"
"It's the Age of Channelwood."
"We should go there on vacation some time."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I don't notice you using too many commas. A lot of German people do use
> too many, though, and it gets annoying after a point...
It's the other way round for me - native English speaker learning German. I
have to learn, that you always need to put the commas in certain places.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I wrote a post here about a logic programming system, which is also an
>> executable logic programming system. ;-)
>
> ...and truly wondrous it was to behold. A tour de force. A masterpiece
> of the programmer's art. Knuth would have been proud. Umm, I'd better
> stop now; Andrew's head is inflating
I'm just going to quietly ignore the obvious fact that you're lying and
enjoy the sweet, sweet afterglow... 0:-)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Gail Shaw wrote:
>> I haven't looked too deeply, but it's on my list of languages to learn.
>
> Speaking of functional, I think Andrew has mildly mischaracterised
> Erlang as a functional language. While I've seen a few informal
> references to needing to use a functional style to program Erlang, none
> of the actual documentation says it's functional, and I never even saw a
> mention of "referential transparency."
Well, people claim that Lisp is an [impure] functional language too, and
AFAIK Erlang is about as pure as Lisp is.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> And it shows, your posts are without exception fluent and well reasoned.
>
> I write too many commas, though.
When I write, I find that I tend to overuse emphasis. (E.g., when I post
things in HTML, I tend to massively overuse the <em> tags...)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
And lo on Mon, 07 Apr 2008 05:44:56 +0100, Gail Shaw sa dot com>
<"<initialsurname"@sentech> did spake, saying:
>
> "Chambers" <ben### [at] pacificwebguycom> wrote in message
> news:47f931ae$1@news.povray.org...
>>
>> The disdain that "real" programmers feel for newbies who crank out quick
>> code using "toy" languages is, I think, more akin to the disdain "real"
>> mathematicians feel towards business math majors. Sure, they can "press
>> the buttons", but they don't really know what they're doing. It's not
>> about jealousy - after all, many programmers who started out writing
>> assembly code are now using higher level languages and cranking out code
>> just as quickly. It's about perceived understanding of what your code
>> actually does.
>
> Agreed.
>
> What bugs me no end is that some people don't want to learn. They're not
> interested in understanding what the code does. They just want to get
> something 'working' (for certain definitions of working) as fast as
> possible.
Time is money - hey it took me a third the time to produce this working
code then you did yours. Oh sure your code scales up whereas mine conks
out with large input, and sure your code is robust whereas mine fails if
someone sneezes at it in the wrong direction; but mine works *now* with
what we're using *now* and it took less time to write then yours - neh neh
neh neh. ;-)
--
Phil Cook
--
I once tried to be apathetic, but I just couldn't be bothered
http://flipc.blogspot.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> What bugs me no end is that some people don't want to learn. They're not
>> interested in understanding what the code does. They just want to get
>> something 'working' (for certain definitions of working) as fast as
>> possible.
>
> Time is money - hey it took me a third the time to produce this working
> code then you did yours. Oh sure your code scales up whereas mine conks
> out with large input, and sure your code is robust whereas mine fails if
> someone sneezes at it in the wrong direction; but mine works *now* with
> what we're using *now* and it took less time to write then yours - neh neh
> neh neh. ;-)
IME it seems that most software that is written in-house is in response to
demands from other people, so there is often huge time pressures on getting
results.
For instance, application A may be developed all very nicely and in time to
do exactly what is needed. It's tested and everything is well, so it is
used regularly. Then one day, employee X comes along and says "hey software
dude, my customer needs result X from the software tomorrow, can you modify
it to give me that info please.". So then software dude modifies the code
in a very hackish way just so that employee X can give some result to his
customer the next day.
The problem is, that then software dude doesn't go back and make everything
nice and test it (he has other stuff to do), the software just gets left in
this "bad" state. Repeat the situation above a few times and you end up
with a big mess.
We have an application here that followed that exact life cycle, you could
see very easily the central well-designed part that someone took a lot of
time over, but the problem was that only accounted for about 10% of the
code. The rest was just ugly hacked on feature after feature.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Bill Pragnell <bil### [at] hotmailcom> wrote:
>>> Warp wrote:
>>>> I have learned to reread everything I write. I reread all my news posts
>>>> before I send them (well, at least if they are longer than a few lines).
>>>> Sometimes I spend more time re-editing and fine-tuning the text than
>>>> I spent writing it for the first time... :P
>
>> And it shows, your posts are without exception fluent and well reasoned.
>
> I write too many commas, though. That's because I tend to instinctively
> put a comma everywhere where I would put it if I were writing in Finnish,
> where commas are used quote a lot. In English commas are used more rarely.
>
> I have lately tried to get rid of this instinct when writing in English.
Commas are tricky... most native speakers aren't too sure where to put
them. I know when they look wrong or right, and when there should be one
when there isn't, but I'm not sure I could describe the rules. I guess
the main thing is to use them to avoid ambiguity when parsing a sentence.
FWIW your comma usage is as correct as anyone else's around here.
Just don't get me started on apostrophes :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> IME it seems that most software that is written in-house is in response
> to demands from other people, so there is often huge time pressures on
> getting results.
That doesn't address the original point of "some people can't be
bothered to learn about stuff", but rather "why software ends up being
poor quality".
> For instance, application A may be developed all very nicely and in time
> to do exactly what is needed. It's tested and everything is well, so it
> is used regularly. Then one day, employee X comes along and says "hey
> software dude, my customer needs result X from the software tomorrow,
> can you modify it to give me that info please.". So then software dude
> modifies the code in a very hackish way just so that employee X can give
> some result to his customer the next day.
Yeah, I'm sure that happens. In fact, it's the kind of thing you see on
the Daily WTF all the time. But, as everybody always points out, the
*real* WTF is that MANAGEMENT FAILED TO ALLOCATE SUFFICIENT RESOURCES.
As with many things, you find it's not a computer problem, it's a human
problem. ;-)
I'm still ****ed off about our project management system. We have a
large and elaborate set of policy documents, procedure documents and
document templates describing how when software is to be developed
in-house, you're supposed to
- Establish a development team.
- Define the scope of the project.
- Produce a set of timelines.
- Plan the user requirements gathering process.
- Select "representatives" from all the affected "user communities" and
iteratively construct a set of user requirements. (Each specific
requirement is numbered for future cross-referencing.)
- Get an authorisation signature for the user requirements document from
management, the developers and all of the user representatives.
[Have you noticed there's no code yet?]
- Construct a technical software design specification.
- Construct a "tracability matrix", describing how each individual
aspect of the proposed software design is directly tracable to one or
more numbered user requirements.
- Have all relevant parties review the design document, ensure that
there are no user requirements missed, check for any potential
regulatory issues, etc. (Possibly requires iterative redesigns.)
- Get authorisation signatures on the design documents from management,
the developers and the user community reps.
[Have you noticed there's no code yet?]
- Write the code for the application, following all the various
guidelines about module naming, comments, algorithm documentation, etc.
- Perform testing. [I'm not even going to go *into* the whole testing
process, but suffice it to say it's every bit as complex as the spec and
design process I just described.]
OK, so here's what really happened:
- The CEO's nephew [are you seeing this??] decided what the system
should do, locked himself in a room for 3 months, and programmed it.
- A team of writers was established.
- They spent about 2 months writing a set of user requirements to match
the actual capabilities of the software actually written. (!!!)
- They wrote up the design of the system and made up design
justifications for the essentially arbitrary design decisions present in
the software.
- They completed the rest of the testing phase.
- They rolled out the software for production use.
It was at *this* point that they suddenly realised "oh, gee, in the UK
they sometimes do projects for customers who are paying in a currency
that ISN'T dollars". [What *should* have happened is that they also
realised "oh, gee, maybe we should have actually ****ing ASKED people
what features the software needs to have rather than just guessing. Hey,
maybe that's why we have this long, complex design process specified in
the first place?" But, obviously, this did not happen.]
Obviously, when you have a large, complex financial processing system
built under the *assumption* that only one currency exists, just adding
the capability to process arbitrary currencies is a "rather nontrivial
operation". Obviously what *should* have occurred at this point is that
people realised "holy crap, we've completely miss-spec'd the system! I
wonder what the hell *else* we got wrong?!" and took the thing back to
the drawing board, or at least for a major redesign iteration.
[Hopefully preceeded by an *actual* requirements gathering phase this
time...]
And, as should be *studendously* obvious, this is not what happened.
What *actually* happened is... what you described, actually. Somebody
took a few days to add a little button that lets you select what
currency you want, and next time you look at the data, it actually
remembers which currency you said.
It doesn't, you know, make any *notice* of the currency or anything. But
it lets you input it, and it displays it. :-)
"How much money did we make last month?"
*whimpers quietly*
And then we get the top-level managers asking why the figures are so odd...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|