I'm considering doing something with Domain Specific Languages for my undergraduate project. My one problem is I can't really find any interesting examples that I can root around in. Does anyone have any good examples of DSELs (preferably open source)?
Also, one area I would love to look at is solving/addressing concurrency problems (coroutines etc) with DSEL's. Are there any good examples that anyone uses of this in DSELs? If this is a stupid application of DSELs please explain why...
Another potential area to explore would database programming. Again is this a stupid area to explore with DSEL's. For example, would adding some crazy database manipulation syntax to C# say be a good project to undertake?
EDIT: General languages I would be looking at implementing in would be Java, Python, Scala, C# etc. Probably not C++ or C.
Linda implementations can be considered as eDSLs. STM implementations like CL-STM are certainly eDSLs.
Unrelated to concurrency, but extremely useful are embedded Prolog implementations, there are plenty of them for Scheme, Lisp and Clojure. Parsing eDSLs had been mentioned already - and their patriarch Parsec definitely worth digging into.
EDIT: with your list of implementation languages you're missing the most interesting eDSL opportunities. The most powerful and flexible eDSLs are made with metaprogramming. Scala-style (or even Haskell-style) eDSLs are based on high order functions, i.e., on mini-interpreters. They're more complicated in design, much less flexible and limited to the syntax of your host language.
boost::spirit if you're after C++ is an interesting example. Quote:
Spirit is a set of C++ libraries for
parsing and output generation
implemented as Domain Specific
Embedded Languages (DSEL)...
(I have no idea what you mean by "solving concurrency" though. I don't see how you can solve "concurrency problems" in general, or how a DSEL could help.)
Related
I'm an experienced software developer, but I've only worked in dynamic languages (primarily Python, PHP in the past, JavaScript, and a little Ruby). Last night, I found myself reading through the tour on the Go website's tour when I realized that the language (syntax, libraries, etc.) would probably be fairly easy to learn, but my lack of knowledge about static/compiled languages would bar me from easy entry. It's not that I don't understand the core concepts of a static language, namely that function argument/variable/return types are static and that a program must be compiled before use. It's more that I don't know where to begin after writing a program. For instance, if I wrote a web application using the Revel framework, it would handle these steps for me (according to the website). Is that pretty typical of frameworks for static languages. Am I worrying too much about a small part of the process that will be quick to learn, or are the (as I call them) formalities of using a static language pretty cumbersome?
As other suggested, any tutorial on Go would work, and you probably worry too much about the dynamic -> static switch. Statically typed languages can be a bit cumbersome sometimes if you come from dynamic typing world, but you'll quickly get used to your compiler yelling at you when types are not correct, and quickly fix it. Eventually, you'll start double guessing it and write (mostly) type-correct code.
Rob Pike noticed that people coming to Go where coming mainly from dynamic languages, which means this cannot be all that hard to do the switch.
There are a lot of tutorials all over the internet titled "Go for ", such as "Go for Rubyists", "Go for Pythonistas" which can help you map your existing knowledge to Go concepts. But as other underlined, the best (only ?) way of properly learning go is to take a tutorial and dive in ! For the books, the standard Effective Go or the very good Programming in Go are very good reads, no matter your background.
Well obviously practice makes perfect, and reading through the extensive documentation. I also find this book really nice Go-lang book, it has some exercises at the end of the chapters which is nice.
Just get a basic tutorial for the language you want and follow it. You will soon pick up how to structure the program. You can then apply your current knowledge of programming to make it do what you want.
I find the (C) API to be very complicated, there are many functions which sound like that they are doing the same thing. The relationship between blob<->image<->registry<->streams> confuses me.
Has anyone found tutorials or can otherwise shed light on what the fundamental concepts of GraphicsMagick are? A few typical workflows like "if you want to work with an image in memory, you can do [...], then to write it to disk, do [...]"
Simple tasks like this are hard.
Probably you have already overcome your problem, but if not- I think that C++ API for GraphicsMagick is quite simple to use in terms that you have specified, see documentation. So if C++ is acceptable for you, it is quite reasonable option.
I'm thinking about creating a simplistic video game. I'm not talking about anything fancy, but about a game like this:
Since I want to learn, I would prefer not to use libraries but roll as much as I can on my own. I'd need to know how to render the car and the track, deal with collision with other cars, etc. I'm targeting Linux, Mac OS X and iOS. I fear that using a library like OpenGL makes things "too simple".
Are there any good resources out there that discuss this? Most of the tutorials / papers I have found are based around popular libraries & engines.
" I fear that using a library like OpenGL makes things "too simple" "
Don't worry, you still have plenty of work left.
In the REAL world, programmers use as many libraries as they can, that is the only way to produce a applications that focus on how things should work and not spend years on every little feature.
Start out programming above libraries, then, if you want to divide down into details, implement your own library and replace the one you used with it.
Dividing your application into self contained parts is a good practice, makes changing it without breaking everything possible.
Also, I would recommend you learn C++ first. Being able to model your problem domain with Object Oriented methodologies will help you break down the problems into solvable units.
Sounds like you're interested in learning from the level of Simple DirectMedia Layer.
If so, this might be a good place to start: http://gamedevgeek.com/tutorials/moving-sprites-with-sdl/
Probably followed by: http://www.gpwiki.org/index.php/SDL#Creating_a_Complete_2D_Engine
Also, for that particular rendering style, see:
http://en.wikipedia.org/wiki/Parallax_scrolling#The_raster_method
http://en.wikipedia.org/wiki/Mode_7
Edit:
This information about the original Doom engine may be useful:
http://fabiensanglard.net/doomIphone/doomClassicRenderer.php
Also, Chocolate Doom is a port of the original Doom source into SDL, so you'll probably learn some useful patterns studying the source for it:
http://www.chocolate-doom.org
It will be more or less impossible to develop a game without using any library. I guess you would have to go back to good old C64 days to do that. If you are interested in learning, I would look for a more low level library, which provides access to graphics, sound, ... But it should leave the logic to you.
I would propose to have a look at http://www.pygame.org/. It makes working with graphics, sprites, ... easy, is still relativly low level and Python is a great language to get started with.
Object-Oriented programmers seem to have all the fun. Not only are they treated to major framework revisions every two years, and new and Improved languages every five, they also get to deal with design practices tailor-made to their programming style. From test-driven development to design patterns, Object-Oriented programmers have a lot to keep up with.
By contrast, the C programming world seems far more sedate. The last major revision to the language was in 1999, and the next one is likely to be far less impressive. K&R 2nd edition is still held up as a good introductory text by many, despite being twenty years old now.
If we, as C programmers, have developed and improved our skills and practices (and I think we probably have), we don't seem to be very good at communicating them. We don't sell books about them, post about them on blogs, or organise workshops around them. Not in the way the rest of the software development world seems to.
So, let's share.
What are your preferred 'modern' C programming practices?
Do you use `template' libraries of long, involved preprocessor macros to squeeze the last inch of performence out of hardware in the same way C++ programmers can? Do you use a allocation library like halloc to minimize the time you spend on managing memory, or do you use a full-blown automatic garbage collector?
Of course, if you've been using these things since 1987, feel free to chime in as well; the point of this question is to share practices that are out of the ordinary but might benefit others.
What are your preferred 'modern' C software design practices?
Design considerations are at least as important, of course. Do you adapt design practices from the Object-Oriented world? Do you use UML? Or you opt to iron out specifications in a language-neutral style (flowcharts, Z, weakest precondition calculus, anything)?
I try to use ready-made libraries for basic functionality when possible. I find glib (part of the GTK+ GUI framework) absolutely brilliant when it comes to general data structures and such. No more writing your own hash table, linked list, dynamic array or whatever.
I also think the object-oriented ideas in the GTK+ toolkit are great, and often structure my code the same. There's nothing stopping you from adopting paradigms in C, it's flexible enough to express many things that are just made "first-class" in other languages, even if doing so often involves a certain ... verbosity, of course.
Not really a C programming practice, because I'm one of those newfangled object-oriented programmers working in C++, but this:
Object Oriented Programming is not a silver bullet
I wish my company had more pure C programmers to teach the juniors that there is life beyond Object Orientation.
To be honest, my answer would be that I finally gave in to C++ after fighting it for a long time. I've come to really enjoy its advantages.
I like being able to let the compiler take care of the OO plumbing, being able to use exceptions and RAII instead of littering return codes and resource releases all over, not reimplementing a linked list or an automatically expanding vector or a smarter string library for the umpteenth time, operator overloading instead of vector_add() everywhere, etc. Granted, there are libraries for much of this in C, but it seems like such things are rather fragmented between competing solutions. It's nice having such amenities standardized in C++.
The nice thing is that I'm still free to drop down and do all the stuff I might have done in C if I feel like that's what suits the program best. There's no OO straight-jacket like in Java.
1999: Use C, it is fast, low-level, efficient
2009: Use Python, it is fast-enough, productive, multi-platform, popular and fun
I would like to hear opinions or peoples experiences regarding Rel. Is it destined for the dustbin, or is it the next big thing in programming? I haven't tried doing anything with it yet (and it looks like you really can't at this point), but I'm intrigued by a few of the concepts discussed in it. Notably:
Removal of nulls completely from the data handling part of the language.
No need for mapping types between the language and the data storage.
Nesting tables
Complete separation of design and implementation.
Thoughts?
I think it is intended as an aid to teaching the pure relational model, not as a competitor to SQL DBMSs for "real work" in the short or medium term. However, Date and Darwen make a compelling case for the proper implementation of the relational model in their book The Third Manifesto. Maybe one day someone will produce a successful product based on it. After all, Oracle was a very small, niche company once!
Right, I agree with you Tony. The interesting thing for me, though, is that Rel is a somewhat working implementation with the understanding that it is essentially a working version of Tutorial D. The thought being that some well funded enterprise takes the research and decides that something like an Industrial D might be worthwhile.
Maybe I'm wrong here, but I get the impression that while Tutorial D is primarily a data language, it has the potential to move into the application space as well. That seems pretty ground-breaking to me. Of course, after reading some of the stuff from Date, Darwen, Pascal, and others, it seems like the language may have the goal of supplanting object oriented programming in general. Right now, OO appears to rule the world of programming. Rel would make available an alternative view on programming in general.
So I guess what I'm curious about is whether this project has legs that leads to other products or if people think it's going to be just a historical curiosity.
Nearly four years on from the OP. I came across Rel recently, and it does have potential for what I am doing. It is more clearly established as a teaching language, but the implementation is now quite solid, though still a little fragile in syntax. It does have potential and I hope that this potential will be realised. Unfortunately this is a similar statement to that made four years ago, so if it is to be realised, it is evidently a very slow burner. Still most research efforts take about 10 years to become embedded in product, so there is still hope.