Board index » delphi » Re: Delphi vs Web/Scripting Languages

2008-05-30 02:30:06 PM
delphi263
Craig Stuntz [TeamB] writes:
borrow something'.
--
m. th.
 

Brian Moelk writes:
are much more harder to find than '{*word*99}py C routines'.
better code, as you say. Then, wouldn't more logical to choose a tool
which gives you
- greater speed - ie. a native code compiler
- better usage of resources (memory, CPU) - ie. no Garbage collectors,
no VM to occupy memory etc.
- more easier deployment - single exe compared with a bunch of files
(the 'runtime') and source code which must be obfuscated in order to
protect your IP?
Imho, your position is in favor of a compiler. And if this compiler is
made x-platform thing which is certainly doable, and it was done by
several projects already (I don't mean now Delphi necessarily) then
where is the advantage of the family of languages which you support?
...but my intent isn't to win a language war, is to enhance my tool in
which it happens to do our programs, knowing very well that this tool
cannot be 'the best of everything for everyone' (btw, Delphi tried that
in the past, as you know - with well known results).
Also, I am afraid to 'win a language war' because there are 'some people'
which can easy say "What I would told you? Our Delphi is the best one. Let's
leave it as a cash cow in a splendid isolation self contemplating it's
eternal glory in the light of the leader of the open ALM revolution."
Not that this can happen, but just to be sure...
I just try to see what are the goods and the bads of this tool from a
critical POV in order to leverage the work which is done by other
communities. And, yes, imho, a tool, as a result of a thinking process
of a team (which is a small community inside in a company/foundation
etc.), can influence the 'outside' community. And, also, the other
informational stream must exist: The community feedback must influence
the tool. that is why I do all these posts. In fact, the most daunting
thing in all this thread (and the 'crux' of it - to cite you) for me was
Robert's statement when I have asked him to vote on certain QC entries:
<quote>
Why would I want that? Do you really believe they would add anything of
this into Delphi?
</quote>
Why a logical developer, as he seems to be, to have reasons to post such
a statement? Because we all know that he have reasons to post it...
Concretely, what/which features do you find useful in Ruby (with which
it seems that you have a certain experience) which, based on your
experience as a programmer, can be 'imported/adapted/implemented (etc.)'
in Delphi?
--
m. th.
 

Robert Giesecke writes:
--
m. th.
 

m. Th. writes:
He did provide a hardcast to TMyType, and then something that looks like a safecast ( "as MyStuff") to
create a variable.
 

Keith Latham writes:
Having usage and declaration as close together as possible, pretty much makes this a non-issue.
I can not possibly see how that could be an issue.
I am just not dogmatic about what my language must not be capable of.
Not in the religious kind of way.
I am happy that is has no "goto", isn't needed anymore by the plethora of smart jump statements.
(method, if, for, while, case, ...)
horrible with-statement that Wirth had removed from Pascal's successors.
begin
var xyz := GetSomeValue();
end;
paragraph?
Have you ever had a try-finally-free block?
This is exactly the same thing, just without the need to declare the var for the whole method or state
its type. And w/o the rather noisy syntax of try-finally-free.
The type gets inferred from the assignment. (no problem, if you actually want to specify the type)
And the language I am using feels very much like Pascal should have felt, just w/o most of the
tediousness and noise.
 

m. Th. writes:
resources don't include human ones, and that greater speed doesn't
include time to market.
[...]
Certainly, I can understand your intent. How many times can the Delphi
community repeat the requests? :)
is that simply because they take different approaches to building an
application, IMO, that doesn't mean that one is more suited to large
scale projects than the other.
--
Brian Moelk
Brain Endeavor LLC
XXXX@XXXXX.COM
 

m. Th. writes:
terms of reducing typing, but it helps a lot and retains all of the
advantages of static typing.
2. First class frameworks for certain problem domains. Easier said
than implemented.
3. The ability to use dynamicism in the cases where there really
aren't any alternatives and it helps a lot (compare Ruby's ActiveRecord
with Delphi's TDataSet with regards to accessing individual field
values).
Plus there are things that are done well by non-dynamic languages, but
which are apropos to this discussion:
1. Optimizations of virtual function performance. The fact that we can
use static functions has perhaps kept us from questioning why virtual
function performance must be worse than static function performance in
all cases. In time-critical situations (e.g., inside a loop), there
are optimizations which can bring virtual function performance close to
static function performance. Java already does this, in the academic
work on the technique is decades old.
2. Garbage collection or some other method of automated memory
management. There are a lot of reasons for this. I have discussed some
of them on my blog. But insofar as this discussion is concerned, the
killer feature here is reduced typing and maintainability of code.
3. First-class functions, lambda expressions, code and types as
objects, etc.
--
Craig Stuntz [TeamB] ?Vertex Systems Corp. ?Columbus, OH
Delphi/InterBase Weblog : blogs.teamb.com/craigstuntz
IB 6 versions prior to 6.0.1.6 are pre-release and may corrupt
your DBs! Open Edition users, get 6.0.1.6 from mers.com
 

Keith Latham writes:
With dynamic typing you don't need type inferencing. When you
inference a type, you have *all* of the advantages of static type
checking.
--
Craig Stuntz [TeamB] ?Vertex Systems Corp. ?Columbus, OH
Delphi/InterBase Weblog : blogs.teamb.com/craigstuntz
Everything You Need to Know About InterBase Character Sets:
blogs.teamb.com/craigstuntz/articles/403.aspx
 

Craig Stuntz [TeamB] writes:
context) should be "infer" (and it wouldn't be you doing it, rather the
compiler <g>).
infer, inferring, inference, inferred, inferable(/inferible/inferrible),
inferably, inferrer, infers, aneurysm.
 

Craig Stuntz [TeamB] writes:
straightforward (imho) like Write(a, b, c) (see, we was one of the first
ones to have type inference! <g>), in the case of functions how do you
see the syntax? Or we should rely only on var parameters like let's say
ReadLn(var a, var b, ...)
Also, if I will open a QC on this, would you vote for it?
- parallel programming (including distributed/cloud computing)
- database access/data binding
- containers, data structures.
variants. (Nick featured it in his blog, btw). Perhaps CG guys will do
something similar, but faster and feature richer, since they have
'everything' (compiler, language specification, IDE, VCL etc.). Only a
little bit of determination perhaps is required...
Btw, I see this in accessing fields (as you noted) like in eg.
MyDataSet.Field1.AsString and in other database actions Eg. locating -
MyDataSet.Field1.Locate('MyVal') - this would improve a lot the
maintainability and as a 2dary effect, speed imho. (QC #56798 - vote for
it! :-) ) Also, the main locate method can be overloaded in
MyDataSet.Locate(aFields: Array of Fields; aValues... ) - with the same
benefits in code quality. (QC #56797 - vote also here!)
virtual methods 'problem' in class helpers..
Programmer controlled Garbage Collection in Delphi') to be submitted by
your truly (did I mention to vote for it?), I have a cold feeling about
the 2ndary effects which a GC can induce. In that report I tried to find
a way in which such an engine can be configurable in order to not
'harm'. What do you think?
even if my nose tells me that we'll have this in Tiburon.
TMethod/TProcedure or perhaps a TCode like in QC #62319 - 'Add the
posibility of metaprogramming / runtime evaluation / runtime compiler'?
And, oh, btw did I mention to vote for it? :-)
HTH,
PS: I am reading a little bit about comprehension lists & tuples in
Python. Can you 'prepare' a little bit on Haskell? I will try (if I'll
have time) to 'attack' you there after we'll advance with this... :-)
--
m. th.
 

m. Th. writes:
--
Craig Stuntz [TeamB] ?Vertex Systems Corp. ?Columbus, OH
Delphi/InterBase Weblog : blogs.teamb.com/craigstuntz
Useful articles about InterBase development:
blogs.teamb.com/craigstuntz/category/21.aspx
 

Keith Latham writes:
enlighten someone!
 

Robert Giesecke writes:
--
m. th.
 

"Yogi Yang 007" <XXXX@XXXXX.COM>writes
better one at the time.