Re: [Vala] Hi, Is Vala what I am looking for?

[Orlando José Luque Moraira <doom79 gmail com>]

Hello!,


Hey, Kratos is my ferret!!!! :D


-- Ildar Mulyukov
> You'd better join the IRC #vala
I have not internet connection at home (for some days!). I cannot use IRC in
the workplace. One day I am able I will enter the #vala from home.


-- Michael B. Trausch
> Welcome to the list.
Thanks you!

> Any C# code would still need to be ported to use it.  [...]
Ok, I understand what you say.


-- Frederik
> Welcome Orlando José, welcome Kratos!
Thanks you very much!

> No, Vala is not intended to be syntax or library compatible with C#.
Ok. It would be nice that yes.

> I'm sure you will like Vala.
I like. I am just finding if I bring my ideas to it.


-------------------------
-- Andres Aragoneses
> That would be very nice to be Vala# a superset of C#, because of a lot of
existing .Net > code which could get better performance. But my idea is not
by this way.


Hmm... Managed code can be implemented so... if you would want to follow
this way, just add this capacity to Vala and activate/desactivate it by the
use of precompiler code?

-------------------------

> For example, method names are written like_this.  This is incompatible
> with java (likeThis) and C# (LikeThis) conventions.
lol. Conventions changes from a project to another project… and from a
company to another. Compilers do not mind if you use one notation or
another.









-----------------------------
-- Michael B. Trausch
> In short, the differences are enough that you'd not be able to use a
> single unified source tree, at least not without a great deal of effort.
> Of course, _anything_ is possible given enough time.  One potential
> solution would be to code in neither, and instead generate the code for
> both.

> For example, you could write a set of GNU m4 macros that would be
> processed against text input to generate the same (functionally
> speaking) code for Vala and for C#.  I don't believe that such a job
> would be terribly easy, mind you, but it would be possible.  The macros
> would have to be able to effectively abstract away all of the
> differences between the two worlds, though; for example, C# has the
> concept of "unsafe" operations, while in Vala, everything just _is_.
> (After all, Vala compiles to C.)

"Chapó"! Just in the bull's-eye!!

That is approximately my idea.

 I am tired of needing one language to do each thing. Needing a library and
seeing a lot in the Internet and that the 95% does not support the
functionality I need, it is incomplete or have Bugs. I am somewhat tired of
being forced to learn and relearn again, mainly from incomplete
documentation or documentation that focuses in the use of
“super-techy-words” instead of focusing in teaching. I am tired of having a
lot of words just to name the same thing which could be explained with a few
common words. I am tired of needing to do 'integration' or other persky
tasks to be able to get some result…



---- I am tired of going to battle with a sword. I want a bazooka!!!! ----


I am looking for a universal combination between language and libraries. The
target of this work is to have a "framework" which can be easily updateable
to be able to support a new machine, device or SO, being supported with a
really powerful language/precompiler_code so adaptation is easier and faster
to any new environment.

The simplified idea is to code a precompiler of a new language which all the
upgrades you want (like Vala by example) which will generate C code (by
example) and then add to the mix:


   - Additional Precompiler code. Like '#ifdef'... but more power, including
   coding auto generation from "scripts". Looking for allowing a more
   tweakeable code.
   - Any additional automatic optimization that could be done.
   - "proxy libraries". There will be a standard framework library.


   - Other upgrades. I have a big list of them like by example a more
   powerful generics system.
   - An intuitive design to minimize learning curve.
   - Very optimized code generation from the precompiler.
   - Add support to objects, aspects…
   - Add support to ambiguous programming. Giving “session” support to be
   able to easy program a client/Server application, a web page or a multi-user
   desktop application. This is maybe a very long term target....
   - Some optional things to be analyzed, like a good garbage collector (and
   I think that the Microsoft one is somewhat primitive).




The library Framework (and any code as desire) will be coded using the
support of precompilation options and code to be able to easily create code
portable to any device/SO combination or to create tweaks or new versions of
an existing component/class.

The precompiler can be done to generate, by example, C code... but I am
looking for a better and easier way to do it. It could be using Vala as a
base.

When you use one component of one of these libraries, internally the
precompiler will use the code adapted to the device and SO that the
compilation is targeted to (wll be able to do so using the help of the
precompiler code and directives). Internally could be just a library working
like a layer between the C program and by example, a threads library. In
windows the library could be the microsoft one. But in linux, PThreads could
be linked instead of the windows one. One function of the precompiler (and
developers) is to optimize this 'layer' up to the point that, performance
speaking, no layer exists.

Other part of the idea is to be able to add 'tweaks' to your code. By
example you create a class. You could add to this class a lot of possible
tweaks and options that allow a developer to fit the component to her/his
needs easily just making an special invocation of the class.


 Yes, a lot of work. But if you code a C++ hardware inventory analyzer for
Linux, you can develop it in this system, use it and share it. Just needed
to be progressive.





----------------------------------------------------------------------------------------
> Just an aside, don't fall into the trap of thinking that just because
> you write code for a managed environment that you cannot have memory
> leaks.  Sure, you won't have memory leaks if you're careful and free
> references, but garbage collectors are all about reference counting.  If
> you still hold a reachable reference to an object, but you're still
> finished with it, you're going to leak memory (in that the garbage
> collector won't release that memory back to the heap on your behalf).
> So, code running in the CLI *can* leak, just as Vala (or C) code can
> leak.
This is an interesting problem. I am thinking about autogeneration in C of
managed code. How to control references, etc.

I think that managed code is a good think.


*You can see that my idea is just additive to any language and compiling
system. I only need to know if I could get this idea done and supported like
part of Vala or not.
*

> Conventions are what keep the world together.  Conventions grow up
> around languages.  There is a reason (other than syntax) why Vala and C#
> code do not look the same, though they are similar.  Conventions matter;
> you cannot disregard them.

You are wrong.

This is the problem that causes, by example, C++ code usually looks like a
cryptic alien message from very-outer space.

I think that it is a common misconception. Conventions can and should evolve
as languages evolves and time go away. A convention should be mainly static
for a project, but dynamic from a project to a newer one.

You must neither get stuck with the conventions (or anything) learned in
university. Universities tend to use old fashioned ways and teachers tend to
have little professional experience in the subject. A lot of learned things
are only good when one is starting like when one is a child and learns that
it is good to poo in the toilet (watercloset) but does not know why. The
conventions are the same. Do your own way. Comunicate. Evolve.

 Nevertheless you should look for code that, being optimized, you can read
them like it was part of a novel book where you can view what is being said
at first glance... just look for “native language coding”.




Best regards,
       Orlando (LanderTaker)






2009/9/24 "Andrés G. Aragoneses" <knocte gmail com>

> Jiří Zárevúcky wrote:
> > On 09/23/2009 05:24 PM, "Andrés G. Aragoneses" wrote:
> > > Jiří Zárevúcky wrote:
> > >
> > > > On 09/21/2009 10:52 PM, "Andrés G. Aragoneses" wrote:
> > > >
> > > > > [...]
> > > > > Of course, what I'm talking about is about adding one more user
> choice,
> > > > > not "removal of Mono" like the subject of the original thread is named
> > > > > (especially if you consider that I work for Novell on some Mono class
> > > > > libraries ;) ). At last, what you could say is "removal of Mono
> > > > > runtime"
> > > > > if we want to refer to this topic.
> > > > >
> > > > > Regards,
> > > > >
> > > > >      Andres
> > > > You can't compile C# code with what Vala uses. It just wouldn't work.
> > > > Ever. C# code is *designed* to work under GC and by replacing Mono with
> > > > something different you achieve nothing. I can't believe people still
> > > > bring up such topics.
> > > Hey Jiri,
> > >
> > > (Short question: with "ever", do you mean even contributing patches to
> > > the Vala Project?)
> > >
> > > Longer questions:  many thanks for your input. Sorry but it's the first
> > > time I see someone mentioning that C# is *designed* to work under GC. I
> > > mean, of course I knew it was, but I didn't know that meant for sure
> > > that it cannot ever work with a reference counting approach. Can you
> > > tell me the exact bits of the C# grammar that would disallow this? I
> > > mean, what's the fundamental difference between Vala language and C#
> > > language (note I'm not talking about runtimes here) in respect to GC?
> > > Let me guess for a sec: are the keywords "owned" and "unowned" related?
> > >
> > > Thanks,
> > >
> > >     Andres
> >
> > You misread me. I'm not talking about C#, I'm talking about code written
>
> Hehe, well if someone says "C# is designed..." then I have to understand
> that.
>
>
> > in it. Changes you would need to do in C# program to make it work with
> > GObject are far from trivial and certainly not doable by a compiler. In
> > another words: porting program from C# to Vala is very difficult even
> > for a human, and I'm not even beginning to think about reflection and
>
> Right, then we're not talking about the same thing. Reflection is an
> API, not part of the language.
>
>
> > such. You essentially need to rewrite it completely, so if the similar
> > syntax led you to believe this is achievable by compiler, you are quite
> > wrong.
>
> Thanks,
>
>        Andrés
>
> --
>
> _______________________________________________
> Vala-list mailing list
> Vala-list gnome org
> http://mail.gnome.org/mailman/listinfo/vala-list