12 replies to this topic

[blurmonk]

Hi

I am trying to find alternative tools and SDKs that can be easier to use when programming graphics. So I ended up finding this language implementation called Ecere? It sounds like it has enough libraries and it implements well know standards.

I am wondering if anyone else has used it successfully in building small apps-projects?

http://www.ecere.com/

thanks

b

[swiftcoder]

<rant>

Congratulations! You have managed to find a programming language so uninteresting, that it was deleted from Wikipedia as 'lacking in notability'. It's actually quite impressive just how many companies/individuals feel the need to reinvent 'C with Classes', and market it as the next best thing...

They also seem to be market-speak language bigots.

And to add insult to injury, despite the giant Apple logo on the front page, their Mac port is unusable.

</rant>

In other words, just ignore eC's existence, and use a language/API that has a chance of actually making your life easier.

C#/XNA is a very popular choice. Python/pygame or Java/LWJGL are also good options for graphics programming. If you are feeling adventurous, Scall/LWJGL is worth a look as well...

[blurmonk]

Swiftcoder,

thanks for the reply. I did not know that they bared some shallow reputation in that way. On the otherhand writing software is not easy, I am sure they spent alot of time on it.

I was just looking for an easier way to do graphics programming. I generally write plugins or scripts for other 3d apps through their Sdks, using C and Python. I am just looking for a familiar programming environment(C like) where graphics is more integrated, I mean that the language features more native feeling graphics library integration if you will, rather than some convoluted imports - includes - initializations and name space stuff, like the way it gets in Python sometimes.

I also would like it to be cross platform since I am either on Linux or Windows.


Btw I remembered that I read your blog the other day about the isosurfaces, what a coincidence. Thanks for the links in your blog entry, they were helpful.

[Ravyne]

It's relatively niche, but you might look into visualization languages like Processing. I'm afraid I don't know much about it myself, but its an entire language aimed at producing visualizations. Its cross-platform, and appears to be well-supported and have a nice community.

[jerstlouis]

Dear blurmonk,

I'm the founder and main developer of the Ecere SDK and the eC programming language.

First, let me tell you I've written tons of applications as well as client solutions using the SDK, and the SDK's components themselves are built with its technology.


You are right we did spend a lot of time working on it, I've been actively developing it since 1996.

Although it is still quite unpopular, it's much more due to attitudes like swiftcoder's than lack of usefulness.

I invite you to try it out for yourself, and if you do please don't hesitate to ask for help, either on our forums or on our IRC channel. We will be pleased to help you.

Best regards,

Jerome

[swiftcoder]

jerstlouis, on 14 February 2012 - 09:53 PM, said:

Although it is still quite unpopular, it's much more due to attitudes like swiftcoder's than lack of usefulness.

Of course it's "useful", just like any other Turing-complete language. Assembly language is "useful" too, but you don't see too many people running out to write the next Crysis using NASM.

I invite you to counter any of my actual criticisms, to whit:

• you have implemented a very basic 'C with Classes', and offer no real features over your competitors in this field (i.e. C++, Java, C,# and D)
  
• your website trashes other languages without any educated rationale
  
• you prominently display an Apple logo, when your Mac support is basically non-existent.

Quite frankly, 2) is my biggest concern. When I visit your site, I see a language written by someone who thinks that "VMs are bad", "Python needs curly braces", and most damningly of all, "Function languages are impractical".

If those are actually your views, then I submit that you are badly under-qualified to design and implement a language. If they aren't, then you should be paying more attention to taking care of your brand identity.

[jerstlouis]

Hi Swiftcoder,

"1.

you have implemented a very basic 'C with Classes', and offer no real features over your competitors in this field (i.e. C++, Java, C,# and D)"

I have implemented a C with classes which satisfied my needs, because none other available did.
eC is not so 'very basic', it's a fairly modern and complete OO language. For example it has reflection support.
eC shares the elegance of C# and Java while it's native like C++.
eC has an import mechanism and does not require the use of header files (which was a big plus for me).
In particular, it makes it easy to package an API library, not having to give out class skeletons including private data members (one of the things I dislike most about C++).

For a little background, the reason I designed eC was because C++ wasn't cutting it, yet I wanted to stay compiled & native, and I wanted to keep coding in C (my Ecere SDK was all written in C until that time).
I was finding C++ pointers usage is ugly, I hated header files, I wanted properties, and I needed reflection to provide a Form Designer with a property sheet in the IDE.

"2.

your website trashes other languages without any educated rationale"

My intention definitely was not to "trash" any other language. All programming languages surely serve a purpose, and I see it as a great feat to design a language.

To make people adopt a language is by far an even greater feat, something I know all too well. So I have great respects for all languages out there.

I was just trying to present the advantages of eC, and what would be reasons to chose eC over other languages.

Any suggestions to improve the comparison to make it look "less trashing" are welcome.

"3. you prominently display an Apple logo, when your Mac support is basically non-existent."

I got fairly excited once we got the IDE up and running (through the X11 server), so maybe I did get a bit carried away.

The idea was to show Ecere is very cross-platform in nature.

We're actually working on improving Mac OS X support right now, with a Cocoa driver.

"VMs are bad", "Python needs curly braces" "Function languages are impractical".

Those ARE my views, i.e. my personal stubborn opinions

, which have nothing to do with qualifications.

I don't pretend to be qualified for anything. I just do my best to achieve my vision of a great SDK.

Those opinions are not meant to offend anyone either, perhaps teasing only ;)

That Wiki was just to get something going. Perhaps it needs improvements to improve perception

Again suggestions are welcome.

Regards,

Jerome

[samoth]

jerstlouis, on 14 February 2012 - 09:53 PM, said:

You are right we did spend a lot of time working on it, I've been actively developing it since 1996.
Although it is still quite unpopular, it's much more due to attitudes like swiftcoder's than lack of usefulness.

If I may make a suggestion, the "language bigot" page that Swiftcoder linked to is a bit unlucky.

From my memory, it reads almost exactly like the "Why Java is so much better than C++" pamphlet by Sun from 1996. Most notably, the "it's like C++, only better because we use . instead of ->, oh and we do GUI" reads very familiar.

Sun wrote almost word by word the same about Java back then. Truth told, Java was in no way better than C++. Performance was abysmal, even smaller programs or applets took considerable time to even start up, and on a somewhat less-than-top-of-the-line computer, you could watch menus being drawn. VM crashes were not alltogether unusual, and the advertized portability was a joke, given 2 available implementations (of which one was Solaris). The threading implementation was extremely poor and entirely missed SMP/HT at the time it became obvious that this would be the next big thing. Downloading the SDK took well over half an hour even at university (which had an -- at that time -- insanely fast 100mbit/s internet link).

However, Java was backed by a multi-million dollar company which invested millions of man-hours in work and millions of dollars in marketing over a decade, pushing Java to become "the one must have feature" in your web browser, and in Sun's "enterprise products" among other things.
Since then, processor power has been increasing, computers have about 10-12 times as much main memory, JIT compilation actually works, VM crashes are practically non-existent, and Java does proper native threading. Which is why in the mean time, their claim has kind of become true. Java no longer totally sucks, it is entirely up to par with C++ and maybe even better in some respects. But it is by no means the only language of its kind, just have a look at C# for a direct competitor of an even bigger multi-million dollar company.

In one word, the bar has been raised quite a bit for "just like C++ only better and without ->" during that time. Which means you have to expect some bad attitude if you use a similar wording. You might gain a more favourable reception if you showed the strengths of your language in a more neutral way. Point out what revolutionary things can be done that are hard in other languages/toolkits, giving some easy (3 lines of code!) examples.

I like the design of your website, by the way. Not sure what it reminds me of, but looks nice.

[jerstlouis]

Thanks samoth.

What you're saying makes me proud.
Though it may be true that eC is not revolutionary (it was never meant to be, it's just a little 'e' on top of 'C').
eC was just meant to be '(real) C with classes done right, done simple'.
Cross platform and elegance without the fuss of a VM and everything else that multi-million dollar company had to go through.

The whole eC SDK, including the cross platform GUI toolkit and everything else, is a small 4mb on top of GCC.
Apps can be statically linked under 1mb with no external dependencies.

If my marketing material is as good as Sun's when it just started with Java, then I didn't do so bad

I made that Learn More page a wiki, so the devs and users could help fix it up and try out new ideas.
Thanks for the 3 lines of code suggestions, I'll try to think of something.

// This is a GUI hello world in eC
MessageBox msgBox { text = "Hello", contents = "hello, world!!" };

This is slightly more than 3 lines, but renders a textured cube with an online image and a sphere:
http://ecere.com/ec/Test3D.ec

http://ecere.com/images/test3DLow.png -- the rendered image

There are a whole bunch of cute samples that comes with the sdk...

All @ https://github.com/e.../master/samples

Cheers,

Jerome

[swiftcoder]

jerstlouis, on 15 February 2012 - 06:10 AM, said:

For a little background, the reason I designed eC was because C++ wasn't cutting it, yet I wanted to stay compiled & native, and I wanted to keep coding in C (my Ecere SDK was all written in C until that time).
I was finding C++ pointers usage is ugly, I hated header files, I wanted properties, and I needed reflection to provide a Form Designer with a property sheet in the IDE.

Ja, you've followed pretty much the same route that D did back in the early days. But what you haven't done is implemented is any of the generics, compile-time meta-programming, or functional programming support - all of which comprise the areas where C++ and D actually stand out from the pack.

Quote

The idea was to show Ecere is very cross-platform in nature.

Every open-source project under the sun claims to be cross-platform. Yet the number that offer a pre-built binary installer for Mac is stunningly small - you're not the only project I take to task over this claim, since it leaves a bad impression on any potential customers.

Quote

"VMs are bad", "Python needs curly braces" "Function languages are impractical".
Those ARE my views, i.e. my personal stubborn opinions

Since when do opinions belong in marketing materials? Especially when those opinions appear to stem from ignorance, thus casting doubt on your credentials.

- Modern JIT (i.e. the JVM, or PyPy) benchmark on par with C/C++ in a number of areas. In general they are 'close enough' to static compiler performance across the board.

- Python's syntax doesn't appeal to everyone, sure, but curly braces are hardly a quote-unquote 'feature'.

- Most of us don't actually like writing software in LISP/etc. but functional programming techniques and tools are incredibly useful. First-class functions, STL-like algorithms, lambdas, etc. have worked their way into pretty much every modern language. Except yours. Why is this?

[jerstlouis]

eC has some generic type support. it can't do everything C++ and D can do, but it's done at loading-time as opposed to compile time.

A pre-built binary installer for Mac would be nice. So would an up to date Windows one!
Sadly, open source projects often have more limited resources than multi-million corporations.

"

Since when do opinions belong in marketing materials?" -- The page you were looking at was a FAQ more than marketing. The SDK is free, I can't afford a marketing team.

Stemming from ignorance? I don't think so. JIT requires extra time for the initial compilation, loading up bunch of stuff, etc.
'Close enough' is just not good enough for me. My philosophy is why should the code run anything more than what you're trying to do?
I saw your article on your blog where you lament about how slow today's software is on today's machine compared to older software on older machines.
It's precisely because of the industry's trends into 'Close enoughs', VM, managed code, and all the like. I guess all that is part of programmers' laziness

STL-like algorithms? eC has got some nice containers with link lists and self-balanced binary trees and such.

Lambdas -- Will have to get those some day but it's not easy to implement in a C based language.

",,,have worked their way into pretty much every modern language. Except yours. Why is this? " -- Simply because that wasn't where the focus was.

But the Ecere SDK remains a great SDK to build small GUI and graphics apps.

[swiftcoder]

jerstlouis, on 15 February 2012 - 11:57 AM, said:

But the Ecere SDK remains a great SDK to build small GUI and graphics apps.

That's an interesting niche. Albeit one where you have to compete with a lot of big players (.NET, Cocoa, QT, the very neat Kivy), and one where native performance is not necessarily a killer feature.

The problem I find, is that when I go hunting for a language to write a GUI application in, I don't really want to have to use a different language to write my web server. This is really one of the key strengths of ecosystems like Python and C#: writing GUI desktop apps is a breeze, but they are equally well geared towards server development, scientific computing, etc.

I'm not really bashing your language here - its nice enough, in so far as it goes. But my impression is that languages tend to survive in the long run either through differentiating features (i.e. Erlang), or through ubiquity (i.e. C, Java). You clearly haven't achieved ubiquity, and you don't really have any differentiating features either...

[blurmonk]

Hey guys

Thanks for the healthy discussion, very informative!