Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #2761 > unrolled thread

EE or CS?

Back to article view | Back to comp.programming

Contents

  EE or CS? bob <bob@coolfone.comze.com> - 2013-01-08 09:28 -0800
    Re: EE or CS? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-01-08 10:41 -0800
    Re: EE or CS? "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2013-01-08 21:41 +0100
      Re: EE or CS? Rui Maciel <rui.maciel@gmail.com> - 2013-01-08 20:50 +0000
        Re: EE or CS? "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2013-01-08 22:25 +0100
          Re: EE or CS? Rui Maciel <rui.maciel@gmail.com> - 2013-01-08 21:35 +0000
            Re: EE or CS? "BartC" <bc@freeuk.com> - 2013-01-08 22:51 +0000
              Re: EE or CS? Rui Maciel <rui.maciel@gmail.com> - 2013-01-08 23:23 +0000
                Re: EE or CS? "BartC" <bc@freeuk.com> - 2013-01-08 23:31 +0000
                  Re: EE or CS? Ian Collins <ian-news@hotmail.com> - 2013-01-09 12:58 +1300
                  Re: EE or CS? Rui Maciel <rui.maciel@gmail.com> - 2013-01-09 01:35 +0000
                    Re: EE or CS? "BartC" <bc@freeuk.com> - 2013-01-09 02:13 +0000
                      Re: EE or CS? Rui Maciel <rui.maciel@gmail.com> - 2013-01-09 11:28 +0000
                        Re: EE or CS? "BartC" <bc@freeuk.com> - 2013-01-09 12:51 +0000
                          Re: EE or CS? BGB <cr88192@hotmail.com> - 2013-01-09 23:52 -0600
                            Re: EE or CS? "BartC" <bc@freeuk.com> - 2013-01-10 12:04 +0000
                              Re: EE or CS? BGB <cr88192@hotmail.com> - 2013-01-10 14:28 -0600
                                Re: EE or CS? "BartC" <bc@freeuk.com> - 2013-01-10 21:58 +0000
                                  Re: EE or CS? BGB <cr88192@hotmail.com> - 2013-01-10 18:25 -0600
                        Re: EE or CS? Patricia Shanahan <pats@acm.org> - 2013-01-09 05:35 -0800
                          Re: EE or CS? BGB <cr88192@hotmail.com> - 2013-01-09 22:43 -0600
                            Re: EE or CS? "BartC" <bc@freeuk.com> - 2013-01-10 12:22 +0000
                              Re: EE or CS? BGB <cr88192@hotmail.com> - 2013-01-10 14:20 -0600
      Re: EE or CS? BGB <cr88192@hotmail.com> - 2013-01-09 22:15 -0600
    Re: EE or CS? Ian Collins <ian-news@hotmail.com> - 2013-01-09 10:19 +1300
    Re: EE or CS? "BartC" <bc@freeuk.com> - 2013-01-08 22:54 +0000
    Re: EE or CS? Robert Miles <robertmilesxyz@gmail.com> - 2013-01-12 16:26 -0800
    Re: EE or CS? Dan <dantex1@aol.com> - 2013-02-19 19:12 -0800
      Re: EE or CS? Rui Maciel <rui.maciel@gmail.com> - 2013-02-20 09:16 +0000
        Re: EE or CS? Dan <dantex1@aol.com> - 2013-02-20 18:59 -0800
          Re: EE or CS? Ian Collins <ian-news@hotmail.com> - 2013-02-21 16:40 +1300
            Re: EE or CS? "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2013-02-21 11:45 +0100
            Re: EE or CS? Rui Maciel <rui.maciel@gmail.com> - 2013-02-21 11:45 +0000
          Re: EE or CS? Rui Maciel <rui.maciel@gmail.com> - 2013-02-21 07:36 +0000

Page 1 of 2  [1] 2  Next page →

#2761 — EE or CS?

Why is it that computer programmers are usually bad at electrical engineering and vice versa?

Or is this just a myth?

[toc] | [next] | [standalone]

#2762

On 1/8/13 9:28 AM, bob wrote:
> Why is it that computer programmers are usually bad at electrical engineering and vice versa?
>
> Or is this just a myth?
I haven't heard that.  I'm actually a programmer by trade, and an 
amateur EE by hobby.

[toc] | [prev] | [next] | [standalone]

#2763

On Tue, 8 Jan 2013 09:28:04 -0800 (PST), bob wrote:

> Why is it that computer programmers are usually bad at electrical engineering and vice versa?
> 
> Or is this just a myth?

Actually worst programmers are mathematicians. Second are physicists.
Engineers are only third.

But yes, a "real programmer" does not know which side of the soldering iron
to hold...

(:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#2764

Dmitry A. Kazakov wrote:

> Actually worst programmers are mathematicians. Second are physicists.
> Engineers are only third.

Dennis Ritchie graduated with degrees in physics and applied mathematics.  
Donald Knuth also has a similar academic career path.  I wouldn't label any 
of them as one of the worse programmers.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#2766

On Tue, 08 Jan 2013 20:50:49 +0000, Rui Maciel wrote:

> Dmitry A. Kazakov wrote:
> 
>> Actually worst programmers are mathematicians. Second are physicists.
>> Engineers are only third.
> 
> Dennis Ritchie graduated with degrees in physics and applied mathematics.  
> Donald Knuth also has a similar academic career path.  I wouldn't label any 
> of them as one of the worse programmers.

I wasn't very serious. But yes, certainly, K&R C, Unix, TeX are vivid
examples of quite poor software architecture and design. C and Unix damaged
progress in programming languages and OS, no less than MS did, IMO.

The weak point of mathematicians is their thinking around algorithms. They
tend to view programming as an algorithmic problem, which is not since late
50's.

P.S. My major was applied mathematics. 

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#2767

Dmitry A. Kazakov wrote:

> I wasn't very serious. But yes, certainly, K&R C, Unix, TeX are vivid
> examples of quite poor software architecture and design. C and Unix
> damaged progress in programming languages and OS, no less than MS did,
> IMO.

Wow.  Surely you are, again, not being very serious.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#2768

"Rui Maciel" <rui.maciel@gmail.com> wrote in message 
news:kci3fn$o44$1@dont-email.me...
> Dmitry A. Kazakov wrote:
>
>> I wasn't very serious. But yes, certainly, K&R C, Unix, TeX are vivid
>> examples of quite poor software architecture and design. C and Unix
>> damaged progress in programming languages and OS, no less than MS did,
>> IMO.
>
> Wow.  Surely you are, again, not being very serious.

He has a point. C and Unix (which I've only seen as Linux) do seem pretty 
terrible products. Successful, yes, but still crude.

-- 
bartc

 

[toc] | [prev] | [next] | [standalone]

#2770

BartC wrote:

> He has a point. C and Unix (which I've only seen as Linux) do seem pretty
> terrible products. Successful, yes, but still crude.

When compared with the state of the art back in 1969?


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#2771

"Rui Maciel" <rui.maciel@gmail.com> wrote in message
news:kci9p6$usl$1@dont-email.me...
> BartC wrote:
>
>> He has a point. C and Unix (which I've only seen as Linux) do seem pretty
>> terrible products. Successful, yes, but still crude.
>
> When compared with the state of the art back in 1969?

No, then they might have been considered quite nifty. But they haven't
changed much over forty years and they're carrying a lot of baggage.

And in the meantime C's syntax has pervaded everywhere, while the 
case-insensitive nature of the Unix is still exasperating a lot of people 
(even those who don't use it!).

-- 
bartc 

[toc] | [prev] | [next] | [standalone]

#2772

BartC wrote:
>
>
> "Rui Maciel" <rui.maciel@gmail.com> wrote in message
> news:kci9p6$usl$1@dont-email.me...
>> BartC wrote:
>>
>>> He has a point. C and Unix (which I've only seen as Linux) do seem pretty
>>> terrible products. Successful, yes, but still crude.
>>
>> When compared with the state of the art back in 1969?
>
> No, then they might have been considered quite nifty. But they haven't
> changed much over forty years and they're carrying a lot of baggage.

Haven't changed much?  Try running a diff on the source (or manuals) for 
an early AT&T UNIX and a contemporary one!

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#2773

BartC wrote:

> No, then they might have been considered quite nifty. But they haven't
> changed much over forty years and they're carrying a lot of baggage.

This is, quite frankly, a load of bullshit.  The man was awarded with the 
Turing Award for implementing Unix, for pete's sake.  Do you feel so 
confident in your judgement to be able to claim that you know better than 
the entire Association for Computing Machinery?

FWIW, Dennis Ritchie's co-author of the original Unix, Ken Thompson, is 
currently working for Google, developing the Go programming language.  Maybe 
he is eager to be taught a thing or two about programming language design 
and implementation.


> And in the meantime C's syntax has pervaded everywhere, while the
> case-insensitive nature of the Unix is still exasperating a lot of people
> (even those who don't use it!).

Could you point out an example of what you've described as "case-insensitive 
nature of the Unix"?


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#2774

"Rui Maciel" <rui.maciel@gmail.com> wrote in message 
news:kcihhn$brq$1@dont-email.me...
> BartC wrote:
>
>> No, then they might have been considered quite nifty. But they haven't
>> changed much over forty years and they're carrying a lot of baggage.

> FWIW, Dennis Ritchie's co-author of the original Unix, Ken Thompson, is
> currently working for Google, developing the Go programming language. 
> Maybe
> he is eager to be taught a thing or two about programming language design
> and implementation.

No-one would dispute that C has an awful lot of quirks.

I'm using it at the moment, via a simple syntax translator to make it more 
palatable, but it still feels like a dinosaur. I'm using it because there 
are good compilers for it and it's more portable than the alternatives, but 
those say little about the language itself.

>> And in the meantime C's syntax has pervaded everywhere, while the
>> case-insensitive nature of the Unix is still exasperating a lot of people
>> (even those who don't use it!).
>
> Could you point out an example of what you've described as
> "case-insensitive
> nature of the Unix"?

I meant case-sensitive...

The fact that you've had to ask, must mean it's even more of an issue than I
thought!

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#2777

BartC wrote:

> No-one would dispute that C has an awful lot of quirks.
> 
> I'm using it at the moment, via a simple syntax translator to make it more
> palatable, but it still feels like a dinosaur. I'm using it because there
> are good compilers for it and it's more portable than the alternatives,
> but those say little about the language itself.

Claiming that, in your opinion, a specific programming language has some 
quirks, is worlds away from claiming that someone is a poor programmer 
because a programming language and a Turing Award-winning operating system 
he developed are "pretty terrible products".

Even so, you will be hard-pressed to point out a single programming language 
whose core language, comparatively, has less quirks than C's.


> I meant case-sensitive...
> 
> The fact that you've had to ask, must mean it's even more of an issue than
> I thought!

Don't try to put words in someone else's mouth.  The reason I had to ask was 
because your assertion regarding the "case-insensitive nature of the Unix" 
was obviously bullshit.  And it was bullshit two-fold: Unix is not "case-
insensitive" in any way, and only those who are completely oblivious to what 
they are doing are annoyed by it.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#2778

"Rui Maciel" <rui.maciel@gmail.com> wrote in message
news:kcjk9h$fdr$1@dont-email.me...
> BartC wrote:
>
>> No-one would dispute that C has an awful lot of quirks.

> Claiming that, in your opinion, a specific programming language has some
> quirks, is worlds away from claiming that someone is a poor programmer
> because a programming language and a Turing Award-winning operating system
> he developed are "pretty terrible products".

I  never mentioned any individuals. The products are admirable achievements
of the time, but are dated and IMO have had too much influence in the
computing world.

> Even so, you will be hard-pressed to point out a single programming
> language
> whose core language, comparatively, has less quirks than C's.

I think the problem will be limiting to list to just one! But it all depends
on what is meant by a 'quirk'. Here's just one of C's: if you write 12 in
the language, it's the constant twelve as you might expect. But if you write
012, with a leading zero, it means ten! OK, one more: accidentally leave out
the closing "*/" of a comment, and see what happens. Likely, nothing, until
your application goes wrong in mysterious ways. There are dozens more...

>> I meant case-sensitive...
>>
>> The fact that you've had to ask, must mean it's even more of an issue
>> than
>> I thought!
>
> Don't try to put words in someone else's mouth.  The reason I had to ask
> was
> because your assertion regarding the "case-insensitive nature of the Unix"
> was obviously bullshit.

I already explained it was a mistake.

>  And it was bullshit two-fold: Unix is not "case-
> insensitive" in any way, and only those who are completely oblivious to
> what
> they are doing are annoyed by it.

And the problem, in case you haven't got it, is that you have to get the
case of a command or filename or option (or URL etc) *just right*,
otherwise the OS has absolutely no idea what you're on about. Or it might be
mistaken for something entirely different and unexpected.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#2783

On 1/9/2013 6:51 AM, BartC wrote:
> "Rui Maciel" <rui.maciel@gmail.com> wrote in message
> news:kcjk9h$fdr$1@dont-email.me...
>> BartC wrote:
>>
>>> No-one would dispute that C has an awful lot of quirks.
>
>> Claiming that, in your opinion, a specific programming language has some
>> quirks, is worlds away from claiming that someone is a poor programmer
>> because a programming language and a Turing Award-winning operating
>> system
>> he developed are "pretty terrible products".
>
> I  never mentioned any individuals. The products are admirable achievements
> of the time, but are dated and IMO have had too much influence in the
> computing world.
>

influence is often a sign of being a successful design...

it is like complaining about how the Quake Engine has had a major 
influence on nearly every 3D game engine created since the 90s.

(nevermind to some extent the influence Carmack has had on the design of 
OpenGL...).


>> Even so, you will be hard-pressed to point out a single programming
>> language
>> whose core language, comparatively, has less quirks than C's.
>
> I think the problem will be limiting to list to just one! But it all
> depends
> on what is meant by a 'quirk'. Here's just one of C's: if you write 12 in
> the language, it's the constant twelve as you might expect. But if you
> write
> 012, with a leading zero, it means ten! OK, one more: accidentally leave
> out
> the closing "*/" of a comment, and see what happens. Likely, nothing, until
> your application goes wrong in mysterious ways. There are dozens more...
>

early on, octal was considered much less arcane.

granted, yes, I would prefer nestable block comments.
in my own language, they are nestable.

however, missing */ will often more likely have a more obvious effect:
if it creates a mismatch in the number of braces, the compiler will 
complain.


>>> I meant case-sensitive...
>>>
>>> The fact that you've had to ask, must mean it's even more of an issue
>>> than
>>> I thought!
>>
>> Don't try to put words in someone else's mouth.  The reason I had to ask
>> was
>> because your assertion regarding the "case-insensitive nature of the
>> Unix"
>> was obviously bullshit.
>
> I already explained it was a mistake.
>
>>  And it was bullshit two-fold: Unix is not "case-
>> insensitive" in any way, and only those who are completely oblivious to
>> what
>> they are doing are annoyed by it.
>
> And the problem, in case you haven't got it, is that you have to get the
> case of a command or filename or option (or URL etc) *just right*,
> otherwise the OS has absolutely no idea what you're on about. Or it
> might be
> mistaken for something entirely different and unexpected.
>

not a big issue...
the alphabet has 52 alphabetic characters...

it is almost too bad we don't have more, for example, we could have 208 
if bold and italic were significant (and could stretch ASCII to around 
380 unique printable characters...).


actually, could almost be done as an ASCII extension, say if special 
control characters / sequences or similar were used, and supported both 
by a text editor and by a language and its libraries (such that string 
operations preserve character modes).

example:
"\e*": Bold Mode;
"\e/": Italic Mode;
"\e#": Bold + Italic;
"\e ": Normal Text;
...

maybe along with:
"\e[": Good old ANSI code;
"\e{" ... "\e}": command or format group;
...

then with nifty keyboard shortcuts to switch between typing in these modes.

well, that or use UTF-8, and make the special commands or extended 
formatted-characters be part of the Unicode space (and/or use some 
combining diacritics for good measure).


because, hell, why not?...


then when typing something (like a command, filename, or variable name), 
then you can also make sure to get the bold and italic just right...

[toc] | [prev] | [next] | [standalone]

#2784

"BGB" <cr88192@hotmail.com> wrote in message
news:kcll2j$6vs$1@news.albasani.net...
> On 1/9/2013 6:51 AM, BartC wrote:

> influence is often a sign of being a successful design...

I did say they were successful. That doesn't mean they are now the best.

>> on what is meant by a 'quirk'. Here's just one of C's: if you write 12 in
>> the language, it's the constant twelve as you might expect. But if you
>> write
>> 012, with a leading zero, it means ten!

> early on, octal was considered much less arcane.

Even so, why choose a designation that is generally regarded as a valid 
decimal number in most other contexts?

Then no-one will ever be able to use leading zero if they so wish. (With the 
quirky but harmless side-effect that, anytime someone writes a zero, they 
are actually writing octal!)

>> And the problem, in case you haven't got it, is that you have to get the
>> case of a command or filename or option (or URL etc) *just right*,
>> otherwise the OS has absolutely no idea what you're on about. Or it
>> might be
>> mistaken for something entirely different and unexpected.
>>
>
> not a big issue...
> the alphabet has 52 alphabetic characters...
>
> it is almost too bad we don't have more, for example, we could have 208 if
> bold and italic were significant (and could stretch ASCII to around 380
> unique printable characters...).

These are just attributes, which are best used for appearance and style
rather than completely changing the meaning of something. What next, colour?

But having said that, I wouldn't particularly object to bold, for example,
being used distinguish keywords from identifiers in a programming language.
(I've seen that done with underlining.)

However, that attribute should apply to the whole word. Without that
restriction, you would have identifiers where every character could be lower
or upper case; bold, italic, bold/italic, or normal; and you can probably
throw in underline and colour into the mix. Every combination would be a 
unique name.

Then you would never need identifiers longer than two or three characters!

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#2787

On 1/10/2013 6:04 AM, BartC wrote:
> "BGB" <cr88192@hotmail.com> wrote in message
> news:kcll2j$6vs$1@news.albasani.net...
>> On 1/9/2013 6:51 AM, BartC wrote:
>
>> influence is often a sign of being a successful design...
>
> I did say they were successful. That doesn't mean they are now the best.
>
>>> on what is meant by a 'quirk'. Here's just one of C's: if you write
>>> 12 in
>>> the language, it's the constant twelve as you might expect. But if you
>>> write
>>> 012, with a leading zero, it means ten!
>
>> early on, octal was considered much less arcane.
>
> Even so, why choose a designation that is generally regarded as a valid
> decimal number in most other contexts?
>
> Then no-one will ever be able to use leading zero if they so wish. (With
> the quirky but harmless side-effect that, anytime someone writes a zero,
> they are actually writing octal!)
>

putting 0 in front of numbers naturally results in evilness though, so 
why do it?...

most common I think is to pad and align numbers with spaces.


granted, yes, maybe "0o1234" or similar would be better.


>>> And the problem, in case you haven't got it, is that you have to get the
>>> case of a command or filename or option (or URL etc) *just right*,
>>> otherwise the OS has absolutely no idea what you're on about. Or it
>>> might be
>>> mistaken for something entirely different and unexpected.
>>>
>>
>> not a big issue...
>> the alphabet has 52 alphabetic characters...
>>
>> it is almost too bad we don't have more, for example, we could have
>> 208 if
>> bold and italic were significant (and could stretch ASCII to around 380
>> unique printable characters...).
>
> These are just attributes, which are best used for appearance and style
> rather than completely changing the meaning of something. What next,
> colour?
>

why not?...
(not being entirely serious here... but this is a logical extension...).


> But having said that, I wouldn't particularly object to bold, for example,
> being used distinguish keywords from identifiers in a programming language.
> (I've seen that done with underlining.)
>
> However, that attribute should apply to the whole word. Without that
> restriction, you would have identifiers where every character could be
> lower
> or upper case; bold, italic, bold/italic, or normal; and you can probably
> throw in underline and colour into the mix. Every combination would be a
> unique name.
>
> Then you would never need identifiers longer than two or three characters!
>

yep, it is a merit. the possible downside though, is that making each 
character a different style, and including lots of options, would make 
typing each character be a dance of keyboard shortcuts...

[toc] | [prev] | [next] | [standalone]

#2788

"BGB" <cr88192@hotmail.com> wrote in message
news:kcn8d3$phv$1@news.albasani.net...
> On 1/10/2013 6:04 AM, BartC wrote:

>> Even so, why choose a designation that is generally regarded as a valid
>> decimal number in most other contexts?

> putting 0 in front of numbers naturally results in evilness though, so why
> do it?...

It *will* be evil if it changes the value of the number!

> most common I think is to pad and align numbers with spaces.

That's true, but the language shouldn't really dictate number style. Leading
zeros on decimals can be useful in a few situations, for the same sorts of
reasons that they are useful in binary and hex: to delimit the number of
digits more clearly, for example, or to highlight a pattern in the digits.
Whatever. Making it mean octal isn't so useful!

And the main point is, with octal being so rare, it can also cause
unexpected bugs.

> granted, yes, maybe "0o1234" or similar would be better.

Or perhaps 8x1234, otherwise, written as 0O1234, it can look confusing.

(For octal, I use either 1234x8, or 1234O, but that latter can also be
written 1234'O. I doubt that will ever be used though.)

>> These are just attributes, which are best used for appearance and style
>> rather than completely changing the meaning of something. What next,
>> colour?
>>
>
> why not?...
> (not being entirely serious here... but this is a logical extension...).

If you want slow down productivity by an order of magnitude, then it's a
great idea! However, the concept seems to work in colorForth.

-- 
bartc 

[toc] | [prev] | [next] | [standalone]

#2789

On 1/10/2013 3:58 PM, BartC wrote:
> "BGB" <cr88192@hotmail.com> wrote in message
> news:kcn8d3$phv$1@news.albasani.net...
>> On 1/10/2013 6:04 AM, BartC wrote:
>
>>> Even so, why choose a designation that is generally regarded as a valid
>>> decimal number in most other contexts?
>
>> putting 0 in front of numbers naturally results in evilness though, so
>> why
>> do it?...
>
> It *will* be evil if it changes the value of the number!
>

that is part of why it is a bad idea not to put 0 in front of numbers...


thinking of it, did go and changed it to '0o', partly as personally I 
have hardly ever used octal for much of anything (and none of my 
existing script code uses octal).


>> most common I think is to pad and align numbers with spaces.
>
> That's true, but the language shouldn't really dictate number style.
> Leading
> zeros on decimals can be useful in a few situations, for the same sorts of
> reasons that they are useful in binary and hex: to delimit the number of
> digits more clearly, for example, or to highlight a pattern in the digits.
> Whatever. Making it mean octal isn't so useful!
>
> And the main point is, with octal being so rare, it can also cause
> unexpected bugs.
>
>> granted, yes, maybe "0o1234" or similar would be better.
>
> Or perhaps 8x1234, otherwise, written as 0O1234, it can look confusing.
>
> (For octal, I use either 1234x8, or 1234O, but that latter can also be
> written 1234'O. I doubt that will ever be used though.)
>

"0o1234" would follow the same pattern as "0x1234" and "0b1010".

"0O1234" wont be recognized by the parser (since only 'o' is recognized).

"0c1234" is also possible (OcTAL).

I guess "0d..." could be added for orthogonality, then:
0bXXXX: binary;
0cXXXX: octal;
0dXXXX: decimal;
0xXXXX: hex.

done, then was followed by some debugging due to stupid errors.

note, it is now possible to type things like:
"0d______69" and "0d00000069".

which will (amazingly) give the same value as... "69".

likewise: "-0d69".


in the process, noticed and fixed a few more bugs related to recent 
type-system changes (arithmetic unnecessarily promoting values to 
double...).


>>> These are just attributes, which are best used for appearance and style
>>> rather than completely changing the meaning of something. What next,
>>> colour?
>>>
>>
>> why not?...
>> (not being entirely serious here... but this is a logical extension...).
>
> If you want slow down productivity by an order of magnitude, then it's a
> great idea! However, the concept seems to work in colorForth.
>

ok.


the idea was originally related to the notion that in specifications, 
bold and italic are commonly used to express meaning as well.

it could be interesting if this were applied to programming languages.


the main downside though would be a matter of the editor, as it could 
couple the language with the text-editor used to write it.

one other possibility though could be that the actual code would be a 
type of lightweight markup, potentially a format vaguely similar to RTF 
or MediaWiki or similar, ...

say:
"This text is [b;bold] and [i;italic], and [u;underlined], or [c4;red]."
probably with an escape character somewhere (such as '\').

[toc] | [prev] | [next] | [standalone]

#2779

On 1/9/2013 3:28 AM, Rui Maciel wrote:
...
> Even so, you will be hard-pressed to point out a single programming language
> whose core language, comparatively, has less quirks than C's.


Also, in analyzing C's "quirks" one needs to consider its original
purpose and requirements. It was intended to be used as an operating
system implementation language. It had to support memory management and
allocation, requiring address manipulation.

Patricia

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.programming

csiph-web