Ah, that explains why I ended up becoming a PHP junkie. ;)On Fri, Dec 18, 2009 at 11:02:30AM -0500, Roger wrote:
In the other hand, Italian to Spanish or Spanish to Italian, not so.
–
-bill!
Sent from my computer
I was joking a bit, because every time a new language comes that is
supposedly
easier to use than C++, ends up approaching C++ complexity up to a certain
point.
The reason is plain simple. Software engineering is a complex area, so in
the beginning
the new language seem attractive, but then people end up adding more and
more features,
reaching to the same point that their “enemy” language was.
Many of the languages that are considered the main ones will eventually get
replaced by another
ones, the same way these languages replaced other existing ones.–
Paulo
On Fri, Dec 18, 2009 at 4:43 PM, Jonathan Dearborn wrote:
I don’t think it has to do with ability. It has to do with comfort.
I know people at work who stick with Fortran… and by Fortran I mean
Fortran 77! They certainly have the ability to grasp more modern
languages (really, Fortran is tough for me to even look at), but other
things hold them back.Jonny D
On Fri, Dec 18, 2009 at 6:48 AM, Paulo Pinto <@Paulo_Pinto> wrote:
Yeah right, maybe we C++ programmers have a brainpower above the
average programmer.On Thu, Dec 17, 2009 at 8:12 PM, Bill Kendrick wrote:
On Thu, Dec 17, 2009 at 02:35:04PM -0200, Cleber Tavares Jr. wrote:
What you guys think about the SFML? I mean, comparing it to SDL
1.2… and
to 1.3? (btw, Sam, when is it gonna come?I asked Google what it was, and saw this snippet of a Wikipedia entry:
Simple and Fast Multimedia Library (SFML) is an object-oriented,
cross-platform, free and open source software multimedia API written
in C++and that’s about where I stopped. (Plain non-object-oriented C is about
all I have the time and brainpower to understand, and it keeps me
happy.)So it’s probably a matter of language taste. (Out of curiosity,
does SFML have bindings to a bunch of other languages, like SDL does?)-bill!
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
As is hinted at by a later posting this is the z-lib license which is
a recognized open source license. It is a very strong version of the
BSD license. Copyright own retains ownership, which is important. It
is important because he then lets you use the code anyway you want to
so long as you agree not to sue him if it doesn’t work out for you.
That is, he gets something of value in exchange for your getting
something of value. That exchange is required to create a valid
contract.
It does let him sell the code, and it lets him change the license and
rerelease it. But, as I understand it, he can not rescind the license
that he has already granted you. If he did, you could sue him. If he
decided to take it private you would still have the rights granted
under the current license to the code you have in your possession.
IMHO this is a great license for the end user and a terrible license
for the copyright holder.
Last spring I spent a few days looking at SFML. I came away feeling
that I would maybe look at it again in a few years. There are some
good ideas in it. OTOH, it didn’t compile. And, I saw evidence that at
least one person involved in the project didn’t understand the
difference between hardware and software rendering.
I was very frustrated by the whole experience.
Bob PendletonOn Thu, Dec 17, 2009 at 2:10 PM, Ricardo Leite wrote:
The License is short, incomplete and … dangerous !
Absence of topics may cause problems in same countries.
The word “Permission” is very fragile in this document.
(Permission of ???, use ?, copy ?, shop ?, advertisement ?)
http://www.sfml-dev.org/license.php
SFML - Copyright © 2007-2008 Laurent Gomila
This software is provided ‘as-is’, without any express or
implied warranty. In no event will the authors be held
liable for any damages arising from the use of this software.Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to alter it and redistributeit freely, subject to the following restrictions:
The origin of this software must not be misrepresented;
you must not claim that you wrote the original software.
If you use this software in a product, an acknowledgmentin the product documentation would be appreciated but
is not required.Altered source versions must be plainly marked as such,
and must not be misrepresented as being the original software.This notice may not be removed or altered from any
source distribution.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
±----------------------------------------------------------
- Bob Pendleton: writer and programmer
- email: Bob at Pendleton.com
- web: www.TheGrumpyProgrammer.com
I was joking a bit, because every time a new language comes that is supposedly
easier to use than C++, ends up approaching C++ complexity up to a certain point.The reason is plain simple. Software engineering is a complex area, so in the beginning
the new language seem attractive, but then people end up adding more and more features,
reaching to the same point that their “enemy” language was.
It’s not that simple. Yes, complex solutions tend to show up as the result of complex
problems, but different languages take different approaches to that complexity, and C++'s
approach is probably the worst possible way in almost every case.
Most of it can be traced back to the fundamental mistake of trying to build a high-level
language on top of C. For example, C has no real string type. String literals are handled
by ugly and dangerous pointer tricks. Most other languages handle this by adding a string
type at the language level. C++ does no such thing, instead leaving it up to designers to
create “string classes.” There are several such classes, which of course aren’t all that
compatible with each other, and many of them contain bugs. There is a “standard” string
class, std::string, but it’s still not a real C++ language string in the sense that other
languages have strings, since string literals still create a char* and not a std::string.
Likewise, in C, you allocate structs on the stack, where they have to be initialized
because they originally contain whatever stack garbage existed at that memory location,
and at the end of the routine, those structs are cleaned up as the stack exits. C++ tried
to follow that model for objects, which tend to be more complex than structs, with
disastrous results. Objects often require destructors, and in order to mix destructors
and stack-cleanup, RAII was invented.
RAII adds hidden code around functions that contain stack-allocated objects, code that
many other languages implement as an explicit feature called a try/finally block. This
hidden code calls the destructors for the stack-allocated objects. But since the objects
aren’t initialized and the constructor may have failed, they could contain stack trash
(or heap trash if they’re allocated with new() ) instead of valid member variables.
Because of this, proper, safe RAII usage requires you to wrap all your references that
require cleaning up in “smart” pointers. Much like strings, the C++ language has no
standard smart pointer language feature, leading to several libraries creating and using
mutually incompatible smart pointer implementations.
Also, since RAII inserts hidden try/finally blocks into the code, someone must have
thought it’s not necessary to actually code try/finally as a language feature. This
means that if you need to ensure cleanup of any other kind, you have to create a
class and instantiate an object that will do it for you through RAII.
It’s a telling point that RAII isn’t found hardly anywhere outside of C++ Land. The
only other language I’m aware of that implements it is D, which based a lot of its object
model off of C++'s. Most languages handle this issue by addressing the underlying
problems instead of treating the symptoms. No allocating objects on the stack, initialize
objects to a known state (usually by zeroing out the address space) before calling the
constructor, and add support for a try/finally language construct, and there’s no need
for RAII (and very little for smart pointers) because the problems it addresses just
don’t exist anymore.
I could provide plenty of other examples, but the simple fact is that while any language
is going to grow in complexity as it addresses increasingly complex problems, the C++
approach to managing complexity tends to be by replacing it with even more
complexity that the programmer has to deal with, whereas most other languages deal
with complexity by implementing language-level solutions to common problems so
that the programmer won’t have to reinvent the same wheels over and over.>From: Paulo Pinto
Subject: Re: [SDL] rival library?
RAII is pretty much the worst possible idiom you could have chosen to
try to argue how C++ handles things poorly.
Likewise, in C, you allocate structs on the stack, where they have to be
initialized
because they originally contain whatever stack garbage existed at that
memory location,
and at the end of the routine, those structs are cleaned up as the stack
exits.? C++ tried
to follow that model for objects, which tend to be more complex than
structs, with
disastrous results.? Objects often require destructors, and in order to mix
destructors
and stack-cleanup, RAII was invented.
Stack allocation and destructors enables RAII, not that RAII is
needed because the idea of stack allocation is broken (it isn’t).
RAII adds hidden code around functions that contain stack-allocated objects,
code that
many other languages implement as an explicit feature called a try/finally
block.? This
hidden code calls the destructors for the stack-allocated objects.? But
since the objects
aren’t initialized and the constructor may have failed, they could contain
stack trash
(or heap trash if they’re allocated with new() ) instead of valid member
variables.
Because of this, proper, safe RAII usage requires you to wrap all your
references that
require cleaning up in “smart” pointers.? Much like strings, the C++
language has no
standard smart pointer language feature, leading to several libraries
creating and using
mutually incompatible smart pointer implementations.
Uh, no. Destructors are guaranteed to be called in reverse order on
fully constructed objects. Smart pointers give you the ability to
not to have to write a destructor at all, and incidentally make it
easier to write exception-safe code.
Also, since RAII inserts hidden try/finally blocks into the code, someone
must have
thought it’s not necessary to actually code try/finally as a language
feature.? This
means that if you need to ensure cleanup of any other kind, you have to
create a
class and instantiate an object that will do it for you through RAII.
RAII is simply the idea that an object is responsible for properly
dealing with the resources it uses. try/finally really just passes
the buck up to the code that uses the class. With great weeping and
code redundancy. It’s easy to forget a try/finally, with RAII you
don’t even need to remember.
It’s a telling point that RAII isn’t found hardly anywhere outside of C++
Land.? The
only other language I’m aware of that implements it is D, which based a lot
of its object
model off of C++'s.? Most languages handle this issue by addressing the
underlying
problems instead of treating the symptoms.? No allocating objects on the
stack, initialize
objects to a known state (usually by zeroing out the address space) before
calling the
constructor, and add support for a try/finally language construct, and
there’s no need
for RAII (and very little for smart pointers) because the problems it
addresses just
don’t exist anymore.
Sure it does, but it’s not called RAII. In C# there’s the "using"
statement, Ruby has Blocks, Python has “with”. They’re all limited by
the use of a GC, though. try/finally solves one problem but gives you
two back. RAII solves the problem and it stays solved.
I could provide plenty of other examples, but the simple fact is that while
any language
is going to grow in complexity as it addresses increasingly complex
problems, the C++
approach to managing complexity tends to be by replacing it with even more
complexity that the programmer has to deal with, whereas most other
languages deal
with complexity by implementing language-level solutions to common problems
so
that the programmer won’t have to reinvent the same wheels over and over.
Things are handled a bit differently when contending with a
10-year-ish ISO standardization cycle and massive amounts of backwards
compatibility. Also, most common problems can be solved quite nicely
using just a library solution without changing the language itself.
To paraphrase The Simpsons, can’t this list go one week without a C++
flamewar?
Surely there are more appropriate lists to argue whether RAII is truly
uglier(!) than finally clauses, and whether strings and smart pointers are
semantically not part of the language, and if that somehow means they are
non-standard and/or we shouldn’t use them.
Gregory
I’m enjoying the reading this discussion. If the topic moves
elsewhere, let me know. 
- StevenOn Fri, Dec 18, 2009 at 2:44 PM, Gregory Smith wrote:
To paraphrase The Simpsons, can’t this list go one week without a C++
flamewar?Surely there are more appropriate lists to argue whether RAII is truly
uglier(!) than finally clauses, and whether strings and smart pointers are
semantically not part of the language, and if that somehow means they are
non-standard and/or we shouldn’t use them.Gregory
Tim Goya wrote:
RAII is pretty much the worst possible idiom you could have chosen to
try to argue how C++ handles things poorly.
Quoted for truth.
I’ve looked at many different “modern” languages, including Java, C#,
Scala, OCaml, and Haskell. All have some very nice features and
improvements over C++. However, they are all missing that one vital
features that trumps all else: RAII. Until a “modern” language can
match this, I’m sticking to C++.
(I have also looked at D. It has RAII, sort of, but it is broken in
various other ways, both at the language level and the implementation
level.)–
Rainer Deyke - rainerd at eldwood.com
Stack allocation and destructors enables RAII, not that RAII is
needed because the idea of stack allocation is broken (it isn’t).
It’s a horribly broken concept. Quite aside from the need for a mess like
RAII to clean up after itself, it breaks compile-time encapsulation. Changing
private members of a class requires all the code that uses it to be
recompiled because you need to know the exact size of the object in order
to allocate the right number of stack bytes. Which wouldn’t be such a
terrible thing in and of itself, except that C++ compilation takes forever and
then some.
Real-world example: Where I work, our main product is a massive 3.5 MLOC
Delphi app, supported by a handful of middle-tier servers. One of the
servers depends on a DLL for a bunch of core functionality, which someone
several years ago decided it would be a good idea to write in C++.
Today the DLL weighs in at somewhere between 200-300 KLOC. On the
same machine, the main app will do a full build in about 2 minutes. The
DLL, more than an order of magnitude smaller, takes about 5 minutes.
Uh, no. Destructors are guaranteed to be called in reverse order on
fully constructed objects. Smart pointers give you the ability to
not to have to write a destructor at all, and incidentally make it
easier to write exception-safe code.
The “exception safety” wouldn’t be nearly such an issue if the objects’
memory space was zeroed out before construction begins. Or, for that
matter, if C++'s version of exception handling wasn’t such a complete
joke.
Also, since RAII inserts hidden try/finally blocks into the code, someone
must have
thought it’s not necessary to actually code try/finally as a language
feature. This
means that if you need to ensure cleanup of any other kind, you have to
create a
class and instantiate an object that will do it for you through RAII.
RAII is simply the idea that an object is responsible for properly
dealing with the resources it uses. try/finally really just passes
the buck up to the code that uses the class.
…which only makes sense if you assume that everything must necessarily
be a class or an object. Follow that line of reasoning too far and you end
up with a big mess like Java.
With great weeping and code redundancy.
I’m sorry, but I have no idea what that means.
It’s easy to forget a try/finally, with RAII you don’t even need to remember.
You still need to remember to set up all your smart pointers, and to use
the right ones for the right types of references.
Sure it does, but it’s not called RAII. In C# there’s the "using"
statement, Ruby has Blocks, Python has “with”. They’re all limited by
the use of a GC, though. try/finally solves one problem but gives you
two back. RAII solves the problem and it stays solved.
They’re not “limited” by the use of a GC, they’re transformed into a
completely different paradigm by the use of a GC. “Using” and
Python’s “with” are both very different from C++ style RAII. I don’t
know enough about Ruby to comment on Blocks, but I’d bet it’s a
very different concept too.
Here’s a problem RAII can’t solve without creating another problem.
Very simple Delphi example:
//prevent linked controls from updating until the dataset is fully populated
MyDataset.DisableControls;
try
LoadDataIntoDataset(MyDataset);
finally
MyDataset.EnableControls;
end;
The finally block ensures that EnableControls will be called, even if an
exception occurs while loading the data. Is there any way to do this in
C++ without creating a new class and instantiating an object of it, which
is a gross hack?
Also, most common problems can be solved quite nicely
using just a library solution without changing the language itself.
To a certain extent, yes, but when you fail to solve basic problems
as a part of the language, (strings!!!) , you end up with multiple
"library solutions" being written to try to solve them, which all end up
incompatible with each other, meaning you have to waste time (and
system resources at runtime) on glue/conversion code in order to
get them to work together properly any time you end up needing
more than one library that implements the same basic concept in
different ways.>----- Original Message ----
From: Tim Goya
Subject: Re: [SDL] rival library?
Tim Goya wrote:
RAII is pretty much the worst possible idiom you could have chosen to
try to argue how C++ handles things poorly.Quoted for truth.
I’ve looked at many different “modern” languages, including Java, C#,
Scala, OCaml, and Haskell. All have some very nice features and
improvements over C++. However, they are all missing that one vital
features that trumps all else: RAII. Until a “modern” language can
match this, I’m sticking to C++.
…wow. Just wow. If you’re that drunk on Kool-Aid, to the point
where you think that this horrible misfeature, a bastard child of two
critical design flaws and father of a third, is not only a good thing
but somehow “the one vital feature that trumps all else,” then
there’s really nothing I can do for you.>----- Original Message ----
From: Rainer Deyke
Subject: Re: [SDL] rival library?
Is there any way to do this
in
C++ without creating a new class and instantiating an object of it,
which
is a gross hack?
/* Terrible Idea! */
try { // stuff }
catch(…) { // more stuff }
Hope that answers your question! :V
Oh no I made an error again by defending C++! 
Nowadays I use mostly what is know as managed languages, after several years
of C++ programming. Those languages provide quite a few nice features over
C++,
in terms of programmers productivity and what is known as application
development.
I still do like C++ a lot and do use it mostly on private projects, when the
need arises.
Surely the language as lots of issues, long compilation time being one of
them. I also
hate the fact that C and C++ still use the idea of translation units, where
each header
has to be parsed thousand times, because there is no way to ensure that
every time it
gets included, the preprocessor will yield the same result.
Not to speak against all those nice features offered by C and C++ that allow
everyone
to explore buffer overflows.
But currently there is no other language which allows the developers to mix
the best
programming paradigms. Enabling the user to programm at low level, to use
object orientation,
generic programming, or functional programming concepts. And most important
portable
across several architectures and operating systems.
Yes the language has a few broken features, which many of us suffer from.
There are also
a few C++0x features that I don’t like at all.
Until there comes a language that is able to offer what C++ has for systems
programming,
performance and portability, the language will stay around, like it or not.
There is a famous paper about this type of issues called “Worse is Better”.
Meaning most
of the best technologies end up dying against worse ones, because people
prefer pragmatic
solutions and are willing to live with worse solutions if they can get good
enough results.–
Paulo
On Sat, Dec 19, 2009 at 6:53 AM, Mason Wheeler wrote:
----- Original Message ----
From: Tim Goya
Subject: Re: [SDL] rival library?Stack allocation and destructors enables RAII, not that RAII is
needed because the idea of stack allocation is broken (it isn’t).It’s a horribly broken concept. Quite aside from the need for a mess like
RAII to clean up after itself, it breaks compile-time encapsulation.
Changing
private members of a class requires all the code that uses it to be
recompiled because you need to know the exact size of the object in order
to allocate the right number of stack bytes. Which wouldn’t be such a
terrible thing in and of itself, except that C++ compilation takes forever
and
then some.Real-world example: Where I work, our main product is a massive 3.5 MLOC
Delphi app, supported by a handful of middle-tier servers. One of the
servers depends on a DLL for a bunch of core functionality, which someone
several years ago decided it would be a good idea to write in C++.Today the DLL weighs in at somewhere between 200-300 KLOC. On the
same machine, the main app will do a full build in about 2 minutes. The
DLL, more than an order of magnitude smaller, takes about 5 minutes.Uh, no. Destructors are guaranteed to be called in reverse order on
fully constructed objects. Smart pointers give you the ability to
not to have to write a destructor at all, and incidentally make it
easier to write exception-safe code.The “exception safety” wouldn’t be nearly such an issue if the objects’
memory space was zeroed out before construction begins. Or, for that
matter, if C++'s version of exception handling wasn’t such a complete
joke.Also, since RAII inserts hidden try/finally blocks into the code,
someonemust have
thought it’s not necessary to actually code try/finally as a language
feature. This
means that if you need to ensure cleanup of any other kind, you have to
create a
class and instantiate an object that will do it for you through RAII.
RAII is simply the idea that an object is responsible for properly
dealing with the resources it uses. try/finally really just passes
the buck up to the code that uses the class.…which only makes sense if you assume that everything must necessarily
be a class or an object. Follow that line of reasoning too far and you end
up with a big mess like Java.With great weeping and code redundancy.
I’m sorry, but I have no idea what that means.
It’s easy to forget a try/finally, with RAII you don’t even need to
remember.You still need to remember to set up all your smart pointers, and to use
the right ones for the right types of references.Sure it does, but it’s not called RAII. In C# there’s the "using"
statement, Ruby has Blocks, Python has “with”. They’re all limited by
the use of a GC, though. try/finally solves one problem but gives you
two back. RAII solves the problem and it stays solved.They’re not “limited” by the use of a GC, they’re transformed into a
completely different paradigm by the use of a GC. “Using” and
Python’s “with” are both very different from C++ style RAII. I don’t
know enough about Ruby to comment on Blocks, but I’d bet it’s a
very different concept too.Here’s a problem RAII can’t solve without creating another problem.
Very simple Delphi example://prevent linked controls from updating until the dataset is fully
populated
MyDataset.DisableControls;
try
LoadDataIntoDataset(MyDataset);
finally
MyDataset.EnableControls;
end;The finally block ensures that EnableControls will be called, even if an
exception occurs while loading the data. Is there any way to do this in
C++ without creating a new class and instantiating an object of it, which
is a gross hack?Also, most common problems can be solved quite nicely
using just a library solution without changing the language itself.To a certain extent, yes, but when you fail to solve basic problems
as a part of the language, (strings!!!) , you end up with multiple
"library solutions" being written to try to solve them, which all end up
incompatible with each other, meaning you have to waste time (and
system resources at runtime) on glue/conversion code in order to
get them to work together properly any time you end up needing
more than one library that implements the same basic concept in
different ways.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Is there any way to do this
in
C++ without creating a new class and instantiating an object of it,
which
is a gross hack?/* Terrible Idea! */
try { // stuff }
catch(…) { // more stuff }Hope that answers your question! :V
No, unfortunately. Unless I’m badly mistaken, the catch(…) code
will only execute if an exception is thrown. The point of a finally
block is that the code will execute no matter what when the flow
of control passes out of the block, whether by an exception,
a return(), or normal program flow.>----- Original Message ----
From: Tres Walsh <tres.walsh at gmail.com>
Subject: Re: [SDL] rival library?
Stack allocation and destructors enables RAII, not that RAII is
needed because the idea of stack allocation is broken (it isn’t).It’s a horribly broken concept. Quite aside from the need for a mess like
RAII to clean up after itself, it breaks compile-time encapsulation. Changing
private members of a class requires all the code that uses it to be
recompiled because you need to know the exact size of the object in order
to allocate the right number of stack bytes. Which wouldn’t be such a
terrible thing in and of itself, except that C++ compilation takes forever and
then some.
Allocating stuff on the stack is an efficient, cache-friendly,
hardware-supported way of using local variables. As long as computing
power is finite, efficiency will be an issue. Which makes the
discussion about stack allocation a little redundant. It’s just the way
today’s computers do things. That’s what registers like ESP and EBP on
x86 are for. C++ is just not high-level enough to ignore the machines
it’s running on. Maybe you want another language.On Fri, 18 Dec 2009 21:53:08 -0800 (PST) Mason Wheeler wrote:
----- Original Message ----
From: Tim Goya
Subject: Re: [SDL] rival library?
But currently there is no other language which allows the developers to mix the best
programming paradigms. Enabling the user to programm at low level, to use object orientation,
generic programming, or functional programming concepts.
You should check out the latest last couple versions of Delphi.
And most important portable across several architectures and operating systems.
No language with any degree of power beyond the “scripting” level is truly portable. Java
comes close, until you try to do non-trivial things with it. I’ve yet to see any serious program
or library in any language that’s portable across several architectures and operating systems
without a mass of ifdefs and tons of compatibility issues.
There is a famous paper about this type of issues called “Worse is Better”. Meaning most
of the best technologies end up dying against worse ones, because people prefer pragmatic
solutions and are willing to live with worse solutions if they can get good enough results.
Yep. And that’s the principal reason why computer security problems have reached
pandemic proportions and are still getting worse more than they get better.>From: Paulo Pinto
Subject: Re: [SDL] rival library?
Allocating stuff on the stack is an efficient, cache-friendly,
hardware-supported way of using local variables. As long as computing
power is finite, efficiency will be an issue. Which makes the
discussion about stack allocation a little redundant.
You’re trading a very minor (dare I say “premature”?) optimization
for all sorts of safety problems. Just look at all the troubles caused
by QT using stack-allocated objects without doing a good job of
documenting what was a value type and what was a reference type.
It’s just the way today’s computers do things. That’s what registers
like ESP and EBP on x86 are for.
Stack allocation is wonderful for value types. But once you get
something that owns references to other variables, it’s more trouble
than it’s worth. Then you’re better off using another x86 feature:
the built-in instructions for dereferencing pointers.
C++ is just not high-level enough to ignore the machines it’s
running on.
Never said it should be. The problem is that C++ ignores the
problem domain. That’s not a matter of high-level or low-level,
it’s a matter of bad language design.
Maybe you want another language.
No “maybe” about it!>----- Original Message ----
From: Johannes Kroll
Subject: Re: [SDL] rival library?
For each systems besides Windows can I use Delphin on?
Free Pascal as kind of Delphi does not count.On Sat, Dec 19, 2009 at 4:33 PM, Mason Wheeler wrote:
>From: Paulo Pinto <@Paulo_Pinto>
**>Subject: Re: [SDL] rival library?But currently there is no other language which allows the developers to
mix the best
programming paradigms. Enabling the user to programm at low level, to use
object orientation,
generic programming, or functional programming concepts.You should check out the latest last couple versions of Delphi.
And most important portable across several architectures and operating
systems.No language with any degree of power beyond the “scripting” level is truly
portable. Java
comes close, until you try to do non-trivial things with it. I’ve yet to
see any serious program
or library in any language that’s portable across several architectures and
operating systems
without a mass of ifdefs and tons of compatibility issues.There is a famous paper about this type of issues called “Worse is
Better”. Meaning most
of the best technologies end up dying against worse ones, because people
prefer pragmatic
solutions and are willing to live with worse solutions if they can get
good enough results.Yep. And that’s the principal reason why computer security problems have
reached
pandemic proportions and are still getting worse more than they get better.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
For each systems besides Windows can I use Delphi on?
Free Pascal as kind of Delphi does not count.
At the moment it’s Windows-only, but the next release (due
out in 2010) is apparently going to have cross-compilers for
OSX and Linux. The team is very committed to
cross-platform development. At the Delphi Live conference
earlier this year, they said that their goal is “native Delphi
everywhere,” including mobile devices. No word on
consoles yet, but I’m trying to keep reminding them of
the possibility whenever I talk with them about platforms.>From: Paulo Pinto
Subject: Re: [SDL] rival library?
Omg. This Mason Wheeler must receive a ban from the World!
Dude, you are trying to argue apple with oranges. Shh.
Stick with your stupid Delphi and lets who understand the things to
talk about it.On Sat, Dec 19, 2009 at 3:51 PM, Mason Wheeler wrote:
From: Paulo Pinto
Subject: Re: [SDL] rival library?For each systems besides Windows can I use Delphi on?
Free Pascal as kind of Delphi does not count.
At the moment it’s Windows-only, but the next release (due
out in 2010) is apparently going to have cross-compilers for
OSX and Linux.? The team is very committed to
cross-platform development.? At the Delphi Live conference
earlier this year, they said that their goal is “native Delphi
everywhere,” including mobile devices.? No word on
consoles yet, but I’m trying to keep reminding them of
the possibility whenever I talk with them about platforms.
I think everyone has the right to have an opinion?
Cheers,
Andre
fungos wrote:> Omg. This Mason Wheeler must receive a ban from the World!
Dude, you are trying to argue apple with oranges. Shh.
Stick with your stupid Delphi and lets who understand the things to
talk about it.On Sat, Dec 19, 2009 at 3:51 PM, Mason Wheeler wrote:
From: Paulo Pinto
Subject: Re: [SDL] rival library?For each systems besides Windows can I use Delphi on?
Free Pascal as kind of Delphi does not count.
At the moment it’s Windows-only, but the next release (due
out in 2010) is apparently going to have cross-compilers for
OSX and Linux. The team is very committed to
cross-platform development. At the Delphi Live conference
earlier this year, they said that their goal is “native Delphi
everywhere,” including mobile devices. No word on
consoles yet, but I’m trying to keep reminding them of
the possibility whenever I talk with them about platforms.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org