 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2012-08-14 04:27, Invisible a écrit :
> Actually, I've never seen Windows 2000 used anywhere, ever. Not in
> people's homes, not in places of work. Indeed, if it weren't for that
> course my employer sent me on, I wouldn't even know it /exists/... It
> never seemed to be really popular.
>
My employer used it on all its desktops and laptops when they upgraded
from Windows 95. So from 2000 to 2005, or thereabouts, you had close to
400,000 users worldwide, in just one company.
My bank also _still_ uses it for the teller PCs. (I suppose bank
tellers are a dying breed, so they figured it was not worth it to
develop a new standard image to be deployed across the country...
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> Valid point. But in a commercial setting, pretty irrelevant.
>>
>> It will become relevant when Microsoft inevitably stops supporting XP.
>>
>> It might not happen next month, or even next year, but the clock is
>> ticking.
>
> What do you mean "when"? This has already happened.
>
> http://en.wikipedia.org/wiki/Windows_XP
>
> "Mainstream support ended 14 April 2009."
Corporate is NOT mainstream. You can bet your ass off that if Bank Of
America, HSBC, LuftHansa, or the Deptartment of Defense finds a weird
problem in XP, they still have ways fo making MS cough up a patch for them.
IBM still unofficially supports OS/2 for the same reason.
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le_Forgeron <lef### [at] free fr> wrote:
> Tetracapilli... if you compile with RTTI (default for most, including
> gnu), an instance of an empty class is already the size of a pointer: to
> the class description.
I don't know how to explain this more clearly than I have already done.
If a class has no virtual functions, it will have no vtable pointer.
RTTI has nothing to do with this.
If you have, for example, one int as its member, the size of the class
will be typically 4 bytes.
Now add a virtual function to the class: Suddenly its size is 8 bytes
(16 if compiling a 64-bit binary). The size of the class has doubled
(quadrupled in 64-bit systems).
This is the reason why vtables are added only to classes that have virtual
functions.
> In Embedded C++, there is no multiple inheritance, no C++ cast (neither
> down or up), no mutable attribut, no namespace, no exception, no
> templates and no stdio.
That sounds like a pretty useless C++.
(Why no namespaces or templates? What do those have anything to do with
embedded systems?)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> - Unsigned integers have names prefixed with "u", and signed integers
> have no prefix. Except byte, which is the other way around: "byte" and
> "sbyte". WTF?
Why would you expect bytes to be signed by default?
> - The "char" type works with Unicode. Well done. Oh, but wait... It only
> stores 16 bits, and yet Unicode actually requires 24 bits to represent a
> single code-point. So this "Unicode character" only actually covers the
> Basic Multilingual Plane. FAIL!
I'm assuming it uses UTF-16.
> - "x + y" performs addition. Unless either argument is a string, in
> which case the other is converted to a string as well (if not a string
> already) and the strings are concatenated. Unless both arguments are
> delegates, in which case they are concatenated. (I guess there's a
> /reason/ the Java guys claim that operator overloading is evil!)
Using operator+ for string concatenation is pretty common. I have never
had any kind of confusion with it. (You would have to come up with a
really artificial example to deliberately make it confusing.)
Automatically converting the right hand side to a string sounds more
dubious to me. Sounds like it may easily be done inadvertently, causing
all kinds of bugs.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 14/08/2012 06:38 PM, Warp wrote:
> Invisible<voi### [at] devnull> wrote:
>> - Unsigned integers have names prefixed with "u", and signed integers
>> have no prefix. Except byte, which is the other way around: "byte" and
>> "sbyte". WTF?
>
> Why would you expect bytes to be signed by default?
I don't know about "default", but a consistent naming scheme would be
nice...
>> - The "char" type works with Unicode. Well done. Oh, but wait... It only
>> stores 16 bits, and yet Unicode actually requires 24 bits to represent a
>> single code-point. So this "Unicode character" only actually covers the
>> Basic Multilingual Plane. FAIL!
>
> I'm assuming it uses UTF-16.
Perhaps actual /strings/ allow storing all possible Unicode code-points.
However, char, the type of a single character, apparently covers the BMP
only. If you're going to go to all the trouble of actually supporting
Unicode, why not support the whole thing?
> Using operator+ for string concatenation is pretty common. I have never
> had any kind of confusion with it. (You would have to come up with a
> really artificial example to deliberately make it confusing.)
>
> Automatically converting the right hand side to a string sounds more
> dubious to me. Sounds like it may easily be done inadvertently, causing
> all kinds of bugs.
Yeah, sounds like more the sort of thing you'd expect in a scripting
language.
OTOH, it appears that it's the only autoconversion that can happen.
Pop quiz: if x is a string and y is a delegate, does it do delegate
concatenation or string concatenation?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 14.08.2012 15:12, schrieb Invisible:
>>> So what do you think Haskell solves inelegantly?
>>>
>>> It's no secret that the libraries lack vast swathes of important
>>> functionality, or that some of the build tools leave a lot to be
>>> desired. But the core language itself? It isn't perfect, but it's a
>>> damn-site more elegant than any other programming language I've ever
>>> laid eyes on.
>>
>> That may well be true, and I actually believe it, but as soon as you
>> want to do some serious programming you'll /need/ more than that elegant
>> core; you'll need those libraries of which /you/ yourself said that
>> various of them suck for this and that reason and none of them gives you
>> exactly what you need.
>>
>> An elegant core language may be nice to have, but if as a consequence it
>> takes you ages to get the job done, unless you make use of plenty
>> non-elegant language extensions or libraries, it doesn't /really/
>> qualify as "a simpler, more elegant design that solves everything".
>
> Right. So you're saying the fact that nobody has sat down and written a
> comprehensive set of libraries makes the language "non-elegant" and
> "poorly designed"?
I did not say THAT.
What I did say is that if nobody has sat down and written a
comprehensive set of libraries, this prevents the lange from being a
language that "solves everything" - and, consequentially, from
qualifying as "a simpler, more elegant design that solves everything".
What I also did imply is that if anybody would indeed sit down and write
a comprehensive cover-all set of libraries, there would likely be quite
a number of them that would be non-elegant to use; and if those
libraries would form a part the language's way of "solving everything",
then THEY would disqualify the combo (core language + libraries) from
qualifying as that "simpler, more elegant design that solves everything".
> Haskell does not have the rich set of libraries that C# has because it
> wasn't developed by a multi-billion dollar global mega corporation. It
> was developed by three beardy guys in a shed on day. If it ever becomes
> popular, we'll see more libraries being developed for it. If (as seems
> more likely) it never becomes really popular, then we won't. But either
> way, this has nothing to do with whether the language is well-designed
> or not.
Right. But it has something to do with whether the language "solves
everything" [for practical purposes].
Can you easily model a state machine in Haskell? If not, then it doesn't
solve everything.
Can you easily write a GUI in Haskell? If not, then it doesn't solve
everything.
Can you easily write an OS kernel in Haskell? If not, then it doesn't
solve everything.
Just three things that immediately spring to my mind; I'm sure there's
gazillions of others out there.
As soon as you have libraries (or other language extensions) for all
conceivable purposes, we'll talk again - about elegancy then.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 14.08.2012 23:06, schrieb Orchid Win7 v1:
> Perhaps actual /strings/ allow storing all possible Unicode code-points.
> However, char, the type of a single character, apparently covers the BMP
> only. If you're going to go to all the trouble of actually supporting
> Unicode, why not support the whole thing?
Do you have any idea what "the whole thing" means in case of Unicode?
Hint: There's more to Unicode than just ~1 million code points with
glyphs mapped to some of them.
> Pop quiz: if x is a string and y is a delegate, does it do delegate
> concatenation or string concatenation?
Provided it doesn't raise an error, obviously you'll get string
concatenation, because you can't convert strings to delegates.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Perhaps actual /strings/ allow storing all possible Unicode code-points.
>> However, char, the type of a single character, apparently covers the BMP
>> only. If you're going to go to all the trouble of actually supporting
>> Unicode, why not support the whole thing?
>
> Do you have any idea what "the whole thing" means in case of Unicode?
>
> Hint: There's more to Unicode than just ~1 million code points with
> glyphs mapped to some of them.
Sure. But if you can't even /write down/ those code-points, that's kinda
limiting.
(It also strikes me that if the String type /can/ hold them all and Char
/can't/, that has interesting implications for trying to iterate over a
String one Char at a time...)
>> Pop quiz: if x is a string and y is a delegate, does it do delegate
>> concatenation or string concatenation?
>
> Provided it doesn't raise an error, obviously you'll get string
> concatenation,
Yes.
> because you can't convert strings to delegates.
No.
From what I can tell, it never tries to convert a string to anything
else, but it /does/ try to convert anything else to a string.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Right. So you're saying the fact that nobody has sat down and written a
>> comprehensive set of libraries makes the language "non-elegant" and
>> "poorly designed"?
>
> I did not say THAT.
>
> What I did say is that if nobody has sat down and written a
> comprehensive set of libraries, this prevents the lange from being a
> language that "solves everything" - and, consequentially, from
> qualifying as "a simpler, more elegant design that solves everything".
Haskell is an elegant, beautiful language. In the vast majority of
cases, it lets you write your application logic in a very concise,
reliable and maintainable way.
For a language to be /useful/, you need more than just the language. You
need libraries. You need a build system. You need packaging and
distribution. You need profiling and debugging tools. You need
documentation systems. And probably a number of other things too.
For the most part, Haskell lacks these. This does not change the fact
that the Haskell /language/ is elegant and beautiful.
I don't doubt that C# almost certainly has /far/ more plentiful
libraries. (As does Java, C++, C, Python, Ruby, or really /any/
programming language that mainstream programmers use.) That doesn't mean
that the design of the C# /language/ is clean or beautiful.
> What I also did imply is that if anybody would indeed sit down and write
> a comprehensive cover-all set of libraries, there would likely be quite
> a number of them that would be non-elegant to use
And why would that be the case?
> Right. But it has something to do with whether the language "solves
> everything" [for practical purposes].
I was referring only to the design of the language itself, not the
libraries that go with it, nor any of the various other tools required
to make a language generally useful. It's no secret that Haskell fails
spectacularly on that count.
> Can you easily model a state machine in Haskell? If not, then it doesn't
> solve everything.
This is trivial.
> Can you easily write a GUI in Haskell? If not, then it doesn't solve
> everything.
This could be made trivial, but currently it isn't supported
particularly well.
(E.g., writing a GTK application is fairly simple. Getting the GTK
libraries to work in the first place is not simple.)
> Can you easily write an OS kernel in Haskell? If not, then it doesn't
> solve everything.
This has been done at least once before.
Note also that there is now a project that lets you run the Haskell
runtime on bare metal (or rather, on the Xen virtualisation platform)
without an OS. Apparently this was developed as part of a commercial
system, so somebody is using it for real.
> As soon as you have libraries (or other language extensions) for all
> conceivable purposes, we'll talk again - about elegancy then.
Right, because how elegant a language is depends on how many libraries
it has. Oh, wait - no it doesn't.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 14/08/2012 03:42 PM, Invisible wrote:
> - The "char" type works with Unicode. Well done. Oh, but wait... It only
> stores 16 bits, and yet Unicode actually requires 24 bits to represent a
> single code-point. So this "Unicode character" only actually covers the
> Basic Multilingual Plane. FAIL!
Oh great. Apparently "char" doesn't store a code-point at all, it stores
a code-unit.
For anything in the BMP, these are effectively the same thing. For
anything outside that range, *you* must manually write the code to
decode UTF-16 into actual code-points (which then do not fit into a "char").
Well done. :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
