These days, I'm most integrating with native libraries, although web browsers are interesting, too. (See perhaps NaCl and Emscripten on the latter.) Some of those libraries export C APIs. That's nice for reuse across languages. Some (Bullet, Skia, ...) do best with the raw C++. This makes interfacing more difficult. One of the best ways to use C++ libraries is to code in C++.
And truth told, especially with C++11, I don't mind coding in C++ myself these days. I like type inference and closures. Bothering with shared_ptr, weak_ptr, and unique_ptr isn't the end of the world, and it gets most resource management done. Eclipse CDT has passable (although quirky and not always reliable) support. On a fast CPU, I can almost survive compile times.
On the down side, C++ is still a complicated beast. I'm not sure I'd like to see results of newbie code in C++ as they try out fancy features (which sometimes really are needed for clean code, too). I also don't understand everything myself. I get the point of C++11 move semantics, for example, but I don't really understand how to use it. I'm sure I could, if I spent time on it, but I sort of hover around "I need to get to that someday" mode. And it's such a bother to have to understand such details. Many other such examples exist in the beast.
Also, there's the issue that I'm really tired of needing to declare functions before defining them and the whole header vs. source files. It seems a small thing, and I could argue their virtues, but it's one of the things I'm most tired of.
In the end, for just getting a job done when I need to integrate, I think C++ is the easiest way to go, and it really is possible to write clean and portable code. However, the warts and slow compiles really grind on me. I'd also like a good implementation I could use everywhere, open standards not withstanding. Maybe that'll be Clang someday, if Windows coding support goes up. Maybe.
I wish the language in my head would fly out automatically with amazing C++ integration support included.
Tuesday, July 31, 2012
Saturday, July 28, 2012
How to be a polite helper
I love to see polite responses like this on help groups. So often I see complaints about people being incompetent or not reading manuals or whatnot. Being polite is wonderful and what's needed if you care about having a good relationship with folks out there. People aren't morons just because they make mistakes. Everyone makes mistakes.
Maybe rude responses are more likely for projects that feel they already have all the attention they want and just can't keep up?
Sorry for not spending the time to look up a counter-example on rudeness, but the polite example is nicer to read anyway. And I guess finger pointing isn't nice either, so maybe it's just as well I haven't looked one up. I guess I could anonymously quote or something.
Maybe rude responses are more likely for projects that feel they already have all the attention they want and just can't keep up?
Sorry for not spending the time to look up a counter-example on rudeness, but the polite example is nicer to read anyway. And I guess finger pointing isn't nice either, so maybe it's just as well I haven't looked one up. I guess I could anonymously quote or something.
Tuesday, July 17, 2012
A closer language: Julia
Well, I can't seem to get language design out of my mind, but someone got really close to what I've been planning: a human-friendly, math-friendly, high speed, scripting-feel, typing-allowed programming language with multiple dispatch and whatnot. The one I found today is called Julia.
It has been well known for the past few months, but I managed to miss it until today.
My (mostly vapor) language is called Rio, and here's some sloppy "brainstorm about the language" demo code.
Some similarities between Rio and Julia are almost uncanny, but there are strong differences, too. Julia has no namespacing (but maybe they'll fix that), emphasizes fully dynamic typing, has too many keywords, doesn't let you really be a peer to core control constructs, has syntactic macros (which I dislike -- but they at least need special syntax and maybe are hygienic?), has batteries included (vs. immediate emphasis on package management), and so on.
But given they already have the buzz, are way ahead of me, and have people paid to work on it, maybe I should throw in the towel and get my own work done, knowing that Julia does a lot of what I wanted.
Some additional differences arise between Julia and Rio, by the way, like how they've gone reference-based and I was leaning value-based, but there are so many pros and cons on such things. That I can follow them down to various subtleties and think about how they've chosen where to go vs. where I have been headed with Rio just lets me know that we've thought about a lot of similar things. Julia just might be my language in the future. Argh. If only for infinite time and money, eh?
It has been well known for the past few months, but I managed to miss it until today.
My (mostly vapor) language is called Rio, and here's some sloppy "brainstorm about the language" demo code.
Some similarities between Rio and Julia are almost uncanny, but there are strong differences, too. Julia has no namespacing (but maybe they'll fix that), emphasizes fully dynamic typing, has too many keywords, doesn't let you really be a peer to core control constructs, has syntactic macros (which I dislike -- but they at least need special syntax and maybe are hygienic?), has batteries included (vs. immediate emphasis on package management), and so on.
But given they already have the buzz, are way ahead of me, and have people paid to work on it, maybe I should throw in the towel and get my own work done, knowing that Julia does a lot of what I wanted.
Some additional differences arise between Julia and Rio, by the way, like how they've gone reference-based and I was leaning value-based, but there are so many pros and cons on such things. That I can follow them down to various subtleties and think about how they've chosen where to go vs. where I have been headed with Rio just lets me know that we've thought about a lot of similar things. Julia just might be my language in the future. Argh. If only for infinite time and money, eh?
Friday, May 25, 2012
Musings on the Rust language
I've looked over many programming languages. I was a big proponent of Fantom for some time. I still think it is one of the best languages in the Java vs. Ruby space, if you know what I mean.
In recent years, though, I've (1) gotten tired of JVM memory hogging and the need for pure-Java-hood, despite its own practicality, and (2) gotten tired of the Java ecosystem and community, especially with the whole Oracle vs. Google thing. Just tired of it. And while I still like Google, I'm not sure I trust them quite as much as I used to. Oh, and (3) related to pure-Java-hood, I've had a lot more need to interface with native code in recent years.
Anyway, I've coded much more C and C++ in recent years than I had for some time. (I've also done a fare share of MATLAB and Python, among other things, including Java.) I like playing native, but C requires so much overhead to get things right, and C++ is such a mess, despite tools like CDT in Eclipse. (Yes, I still use Eclipse despite its Java core.) I'm also just tired of header vs. source files and bother like that.
I'm also a programming language hungry sort, so I've looked at languages like Go, D, Rust, and Vala that aim to make low-level coding more pleasant and safer. I'm not sure I like D originating from a propriety land, even with open implementations, and Vala is too locked into glib land among other issues. I also buy Rust's arguments against Go's global variables and lack of automatic resource management. I also can't stand being expected to check for error responses every time. That's Go's official way of dealing with errors, although they have a discouraged form of exception handling in the form of panics. Rust also has no exceptions, but you are allowed to crash your task (coroutine) and recover from another. That's acceptable to me. That's what errors are for, really.
I also actually like functional programming despite my complaints at complicated languages like Scala. I'm not sure yet whether Rust is any better, but I think it has enough of the core things right while still being low level.
Anyway, Rust isn't what I'd design by a long shot. (The language Clay is closer in overall feel, but it's not as likely to go mainstream, and I'd actually go higher level than either Rust or Clay myself, although I'd want to retain the ability to call straight into C and maybe even C++ libs.) However, with its momentum, is Rust good enough?
I don't know, but there's a chance that Rust will become my tool of choice in the future.
Sorry no time to go into the particulars of my feelings on all the little issues.
For now, though, realize that Rust is in a heavy state of flux. That much is clear. Before 1.0 comes out, I expect a lot of things will change, and the current latest features (as for any project) risk being buggy. Documentation also lags some. Just a heads up.
In recent years, though, I've (1) gotten tired of JVM memory hogging and the need for pure-Java-hood, despite its own practicality, and (2) gotten tired of the Java ecosystem and community, especially with the whole Oracle vs. Google thing. Just tired of it. And while I still like Google, I'm not sure I trust them quite as much as I used to. Oh, and (3) related to pure-Java-hood, I've had a lot more need to interface with native code in recent years.
Anyway, I've coded much more C and C++ in recent years than I had for some time. (I've also done a fare share of MATLAB and Python, among other things, including Java.) I like playing native, but C requires so much overhead to get things right, and C++ is such a mess, despite tools like CDT in Eclipse. (Yes, I still use Eclipse despite its Java core.) I'm also just tired of header vs. source files and bother like that.
I'm also a programming language hungry sort, so I've looked at languages like Go, D, Rust, and Vala that aim to make low-level coding more pleasant and safer. I'm not sure I like D originating from a propriety land, even with open implementations, and Vala is too locked into glib land among other issues. I also buy Rust's arguments against Go's global variables and lack of automatic resource management. I also can't stand being expected to check for error responses every time. That's Go's official way of dealing with errors, although they have a discouraged form of exception handling in the form of panics. Rust also has no exceptions, but you are allowed to crash your task (coroutine) and recover from another. That's acceptable to me. That's what errors are for, really.
I also actually like functional programming despite my complaints at complicated languages like Scala. I'm not sure yet whether Rust is any better, but I think it has enough of the core things right while still being low level.
Anyway, Rust isn't what I'd design by a long shot. (The language Clay is closer in overall feel, but it's not as likely to go mainstream, and I'd actually go higher level than either Rust or Clay myself, although I'd want to retain the ability to call straight into C and maybe even C++ libs.) However, with its momentum, is Rust good enough?
I don't know, but there's a chance that Rust will become my tool of choice in the future.
Sorry no time to go into the particulars of my feelings on all the little issues.
For now, though, realize that Rust is in a heavy state of flux. That much is clear. Before 1.0 comes out, I expect a lot of things will change, and the current latest features (as for any project) risk being buggy. Documentation also lags some. Just a heads up.
Wednesday, May 16, 2012
Piano keyboard & musical staff figure
For three semesters, I've taught a course on programming in C. I like to give a particular application domain for the final exam and let them solve multiple problems in that context. This past semester (and my last for the foreseeable future), I chose sheet music.
Knowing that many people aren't familiar with sheet music but that some are, I gave a quick crash course in the exam itself. Seems crazy, but I simplified things, and I ran it past multiple folks with little to no music experience. Overall, it worked out. However, for my quick summary, I wanted a figure of a piano keyboard in context with a musical staff. I had trouble finding anything else out there that met my needs.
So I made something:
I also have a pure SVG version of that, but Blogger doesn't let me attach SVGs. How modern of them. Maybe I should go to WordPress sometime.
Anyway, I hope some folks find this figure useful. Let me know if you want the SVG. The figure is public domain, so far as I'm concerned.
Credits: LilyPond, Frescobaldi, LibreOffice, and Inkscape.
Knowing that many people aren't familiar with sheet music but that some are, I gave a quick crash course in the exam itself. Seems crazy, but I simplified things, and I ran it past multiple folks with little to no music experience. Overall, it worked out. However, for my quick summary, I wanted a figure of a piano keyboard in context with a musical staff. I had trouble finding anything else out there that met my needs.
So I made something:
I also have a pure SVG version of that, but Blogger doesn't let me attach SVGs. How modern of them. Maybe I should go to WordPress sometime.
Anyway, I hope some folks find this figure useful. Let me know if you want the SVG. The figure is public domain, so far as I'm concerned.
Credits: LilyPond, Frescobaldi, LibreOffice, and Inkscape.
Monday, October 10, 2011
Google's Dart is nothing new
Ran across Google's Dart programming language today with an announcement they made.
Those design goals are interesting. Hrmm. Only Node.js and GWT target client and server? How about Fantom and haXe? I suspect there are many more. I'm just mentioning ones that I'm most familiar with. I haven't gone on a link search.
I think Fantom is especially aligned with many of the goals of Dart. But making one's own language is fun (and time-consuming). Been there before myself. Maybe again someday. In addition to having been around longer, Fantom has the benefit of the compiler being implemented in Fantom. Dart seems not to be self-hosted yet. Maybe they'll get there someday.
Meanwhile, if Dart sounds interesting to you, I'd recommend taking a look at Fantom first. It even has Eclipse and NetBeans plugins already.
Update: It seems Google Dart has some Eclipse IDE stuff in the works, but I'm having trouble finding detailed discussions on it.
Update 2: I also missed the native VM. With the compiler in Java, I wrongly assumed the whole back end thing was Java-based despite their discussion of a VM for Dart.
Update 3: It seems Gilad Bracha's involved, and the type system is more dynamically-focused than I thought at first glance. I'm concerned that making types too optional will make code tooling weaker, but maybe they have clever tricks planned for performance and tooling. (I mean, V8's pretty good at performance with little-to-no static type information at all.) On the happy side, generics are reified.
Those design goals are interesting. Hrmm. Only Node.js and GWT target client and server? How about Fantom and haXe? I suspect there are many more. I'm just mentioning ones that I'm most familiar with. I haven't gone on a link search.
I think Fantom is especially aligned with many of the goals of Dart. But making one's own language is fun (and time-consuming). Been there before myself. Maybe again someday. In addition to having been around longer, Fantom has the benefit of the compiler being implemented in Fantom. Dart seems not to be self-hosted yet. Maybe they'll get there someday.
Meanwhile, if Dart sounds interesting to you, I'd recommend taking a look at Fantom first. It even has Eclipse and NetBeans plugins already.
Update: It seems Google Dart has some Eclipse IDE stuff in the works, but I'm having trouble finding detailed discussions on it.
Update 2: I also missed the native VM. With the compiler in Java, I wrongly assumed the whole back end thing was Java-based despite their discussion of a VM for Dart.
Update 3: It seems Gilad Bracha's involved, and the type system is more dynamically-focused than I thought at first glance. I'm concerned that making types too optional will make code tooling weaker, but maybe they have clever tricks planned for performance and tooling. (I mean, V8's pretty good at performance with little-to-no static type information at all.) On the happy side, generics are reified.
Saturday, July 16, 2011
Thanks for git, Google!
I assume everyone else is in the know by now, too, but I still wanted to say a public thank you to Google for supporting git at Google Project Hosting.
Now I need to decide if it's worth the effort to consider switching from GitHub. I don't even know if Google supports the sweetly convenient ssh keys thing. At first glance, I don't see it.
At least I know git is an option at Google now, should I decide to go back.
Now I need to decide if it's worth the effort to consider switching from GitHub. I don't even know if Google supports the sweetly convenient ssh keys thing. At first glance, I don't see it.
At least I know git is an option at Google now, should I decide to go back.
Subscribe to:
Posts (Atom)
