We Keep Coding

Are Project-Specific DSLs a Liability? [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I've forked this question from a similar question I made in a comment I made to one of the many great answers I recieved. I was originally asking about AST macros, which mostly provoked very detailed and thoughtful responses from Lispers. Thanks.
Lazy Evaluation vs Macros
The question I made in a comment was whether project-specific DSLs are actually a good idea. Of course, this is completely subjective -- After all, when you are writing in a really expressive language, where do you draw the line between an expressive API and an actual DSL? For example, I think what most Rubyists call 'DSLs' are actually just well-designed APIs and nothing more.
Note that I say project-specific APIs. I don't think many will argue against using regular expressions or SQL where it makes sense to do so.
But despite this, I think we can all draw a vauge, hazy line between an API and a DSL. Of course they're both really APIs, but whatever.
On one extreme you have Lisp, where DSLs seem to be actively encouraged via macros. On the other you have the likes of Java where DSLs are pretty much impossible.
Proponents of DSLs would argue that they increase flexibility, expressiveness, and increase consistency (for example, a custom number object using the same operators as the language's own numbers).
Detractors would say that they can lead to sub-languages that nobody except the DSL writer knows, kills the point of having different programming languages in the first place, and leads to code nobody can understand because the way of interfacing with API is different.
I gotta say, I agree with both sides in many ways. Some Java APIs are just plain nasty due to the lack of expressiveness. Despite this, I can generally always work out what's going on without reading the documentation -- Which can't be said about custom DSLs in the slightest. Maybe DSL proponents argue that you should always read API documentation. I disagree, but I also digress.
But let's look at some of the big languages at the moment. C# and Java, namely. Neither of them really 'do' DSLs, yet they're massively popular. Is this precisely because they don't allow things like DSLs, allowing mediocre coders to churn out code that's still comprehensible?
Is the fact that DSLs allow mediocre coders to produce impenetrable garbage the reason why Lisp is not used as much as it should be, despite what a DSL can look like in the right hands?

There are of course arguments in favor of DSLs and against them, and there's of course a vague line between "a library" or "an API" and "a DSL". That part you've covered well in the question, so I'll avoid those subjective points and focus on just the question of whether they're a liability.
A good project to consider for this is Racket which puts language construction as its main feature. It's easy to slap up a language for any definition of "a language": DSL or not, made up from near scratch via an interpreter or (more commonly) done via macros that define the new language and possibly a parser for a different syntax. As a result, the Racket source tree has a bunch of languages -- some of them have fundamentally different execution semantics. Some examples:
Lazy Racket is what you'd expect the name to mean,
Typed Racket is a statically typed language,
Scribble is a language for writing documentation and other prose,
Slideshow is a language for writing ... slideshows,
RackLog/DataLog are languages that are even more different in both semantics and syntax.
In fact, making up languages is so easy in Racket, that you easily slap up a language even if it's something that fits a very limited use, or even just a single one. For example, we have such "small languages" that are used to create our web pages, decide which files are included in distributed installers, and many many more. See this tutorial for a description of how to come up with a language.
It's true that there's a fine line between a useful DSL that many people can use and one that only one person uses -- but still, the kind of abstractions that you can get when you define a language rather than a library are substantial, to the point that it's a useful concept even when it's a "one-man's language". One hard problem in this are is considering interoperability -- Racket allows each module to be written in it's own language, which brings up issues of what happens when several of these modules are supposed to talk to each other. For example, how does evaluation proceeds when there's interaction of functions in the lazy language and in the default one; or how does the typed make sure that it can interact with the default untyped language and still get the usual benefits of a statically typed language.

DSLs are widely used in Java. Just not 'internal' DSLs. Lisp has, unlike Java, several ways to alter the language syntax and semantics without writing a new external language. In Java, most DSLs are either external (often based on XML) or implemented with a pre-processor.
If you write a new programming language, also a domain-specific programming language, you need to:
specify it
document it
test it
make it robust
make it debuggable
make it efficient
... and more
Lisp is no magic bullet to do all that for you. What Lisp gives you is to include one or more DSLs directly into the language and it allows you to reuse or alter the Lisp facilities to implement parts of your new language.
Lisp had in its history a lot of languages implemented on top of it. Many of them were just research languages without too much effort to follow software engineering practices. Some of these languages had more effort put into them - for example because they were part of a product.
If you develop a language for your project, you need to make sure that you follow good software engineering practices and you have the resources to do so.

Learning functional programming

I am mostly a Java developer, this is where I've had the most experience. I want to improve my coding skills so I am looking at learning a functional language.
I don't want it to be too big a leap for me, I don't want to get bogged down in too many unfamiliar things, I'd like to get up to speed as soon as possible.
Can you recommed a language/platform for my first serious look at functional programming?

To be honest, it's the big leap in perspective that makes learning a functional language such a benefit. I'd say dive in the deep end with the "purest" functional language Haskell.
The books Real World Haskell and The Haskell School of Expression are great introductions.

Try Scala. It's not purely a functional programming language, but it fits right into your toolbox. See Learning Scala.
Another option may be Clojure. That, too, isn't pure FP, but as a Lisp dialect it offers many of the relevant features.

Give yeti a try. This is an advanced ml dialect on the jvm
It is pure functional, integrates nice with Java, is statically typed and is much simpler than ie scala. Has a simpler type-syste, but with full type-inference.
http://mth.github.com/yeti/

Scala was designed with Java and the JVM in mind. Sounds like a nice place to start.
official web site

FunctionalJava is the best known library to start functional programming in Java.

Several possibilities. Scala runs on JVM, so you can use Java library for a lot of things. I am not a fan, it is way too complex, with lots of syntax to learn.
Scheme is arguably the best language for learning FP, because you can learn the syntax in 30 minutes.
You can also take a look at hybrid languages, like JavaScript, which also have some aspects of a functional language (most importantly, closures), yet keep the procedural tradition syntax.

As a new programmer of Java,you'd better see the function things of Java area,like Effective Java、*the offical API of Java* and many many others.By the way,i like the Oreilly's Book.

As you are very much interested to learn a functional language, I would suggest Ocaml(Objective Caml). I can suggest you a good book to learn functional programming and lambda calculus.
Types and programming Languages by Benjamin C. Pierce.
http://www.cis.upenn.edu/~bcpierce/tapl/

If you have time to read a book, please try "Effective Java" . It's a very good book for developers.

Knowing the fundamentals of Java what is the right approach to learn Groovy?

As my question already implies I want to learn a new language and have read several articles about groovy and its more pragmatic syntax. SO I have choosen Groovy as the language of my choice.
What is a good way to learn a new language like Groovy when I already know the fundamentals of Java. When I understand correctly Groovy will be running in the Java Virtual Machine and allows me to always rely on what I know from Java when I don't know how to solve the problem in Groovy.
I am looking for hints on how to organize a learning track to learn this language. I found that page explaining the differences: http://groovy.codehaus.org/Differences+from+Java But what I am looking for is more a tutorial where I can get through and get introduced to the differences.

There are a couple of articles which have been written with that specific goal in mind: "From Java to Groovy in a few easy steps", part 1 and part 2. They were written by Gillaume Laforge, one of the masterminds behind Groovy. The articles are well written, easy to follow and provide a nice introduction for Java developers. Also, there is the Beginners tutorial in the official Groovy documentation.
Once comfortable with the basics, it's easy to move on to the on-line Groovy task-specific documentation.

Personally I find that referencing an old language that I know to learn a new language is not a good idea. The reason I say this is that in a new language you want to learn to express and use data structures, idioms, style, etc in THAT language. You want to Groovy developers to say that the code is written by a Groovy developer rather than a Java developer.
An example, using Groovy and Java, is that Java developers tend to use a loop for collections, but in Groovy tend to use closure. They may look the same, but they are not. In Java we are applying to data to the code, whereas in Groovy we are applying the code to data. Learning this subtle difference is important to understanding the rest of Groovy API and will help you to grasp that concept.
Also I think that this approach of learning a new language referencing and old might not work that well with other styles of programming like functional.

You might also take a look at this article by James Strachan, the author of Groovy:
http://macstrac.blogspot.com/2009/04/scala-as-long-term-replacement-for.html

Which is more similar to AS3, Java or C++?

I am ActionScript 3/Flex programmer, it is the first language I learned.
I want to learn either Java or C++.
Would one of these be easier to learn based on my current knowledge?

It really depends what you want to do. C++ is more powerful and fast. But Java has a smaller learning curve.
I'd say learn C++, only because it will require you to gain a better understanding of how computers work under the hood. It will also help position you to learn Java, C#, or any other language down the road.

Java seems more likely to be directly relatable to your work in AS3; C++ is better for giving you a grounding in a different technology (pointer-style OO rather than object-style. C++ may feel eerily similar yet different).
If you are doing C-ish C++, the pointer language learning process can be very informative as to how OS-level calls are written...
The places where you will reach for one tool or the other are very different, and the use you have for the tool may be more important in deciding than their relative merits as languages - employability IS a use for a tool, after all.

Well, AS3 more closely resembles JavaScript - they both follow the ECMAScript specification.
But to answer your question, I would say learning Java will be more beneficial and easier for you. Java supports Interfaces, and single inheritance, like Flex, whereas C++ supports multiple inheritance and lacks a formal notion of Interfaces. Java and Flex both manage memory for you, whereas C++ forces you to manage your own memory. Both Java and Flex have large helper libraries out of the box, and both have native String types, whereas C++ forces you to find a library to use and doesn't support native String types.
This may be my own bias, but it also seems more likely that you'll find a job that is looking for a Flex/Java developer, rather than a Flex/C++ developer. Java and Flex seem to work well together, with Flex as a front end and Java as a middle and back end.

I would say Java is more similar to AS3 than C++. You will find lots of familiar metaphors and mechanisms.
C++ on the other hand, will require more effort to learn. It is closer to the machine and demands an undertanding of lower level mechanisms. For instance, there is no garbage collection so you have to manage your memory resources yourself.
Which is better to know depends on what you plan to do with the language. C++ is good at performance critical applications (games, all kinds of real time simulations etc.). Java makes it easier and safer to build things, but at the cost of performance.
hope this helps
regards

C++ is, generally, harder to learn than Java. You will find this true pretty much no matter what your previous experience. Therefore, if you want to learn the easier, learn Java.
(This is partly a matter of design philosophy. C++ was designed to be mostly upward compatible from C, at least the C at the time C++ was being designed. It was also designed
to be useful and permissive, with ease of learning being secondary. Java was designed partly as a reaction to C++, as a generally safer and easier language. C++ is more expressive than Java, but this comes at a price: it's harder to learn C++, and easier to screw up with it.)
That being said, you never said why you wanted to learn another language. You might well be better off learning C++, even though it is more difficult.

Whatever you'll finally decide to learn, do yourself a favor and read either Thinking in Java or Thinking in C++.
Both books are available - for free! - at Bruce Eckels website. They are very, very good.
C++ is more complex than Java so I'd suggest to take a look at Java, first.
However, this isn't meant as C++ bashing. Both are great language, it just depends on what you'd like to do in the end.

I would go with Java. It will be easier to learn and, given your background, I'm guessing you do more web/internet work in which case you'll probably find more ways to apply the Java knowledge then you would C++.

I think you would find Java more similar.
Learning C++ will likely require you to learn concepts that you could avoid with other high level languages (such Java and AS3) e.g. manual memory management, pointers, non forward looking compiler, multiple inheritance, etc.

Best approach for learning Java after C++?

I've been using C++ for about 6 or 7 years now, and I consider myself fluent in it. I've never bothered with Java until now, but I find myself out of the job (company went under) and I need to expand my skill set. Someone recommended Java, so I am wondering if there is any advice for where somebody like me might start. I am also interested to know what the key aspects of Java are that are most likely to come up in an interview.

There are some popular areas that I think of when we talk about Java
Concepts of OOP: I'm sure this will not be much different from C++:
Class, Abstract Class, Interface,
Polymorphism, Overriding,
Overloading, Inheritance, Static
member, ... Interface will likely be
area that you might want to focus.
Since this is not directly available
in C++, I don't know.
Core Java: Such as the basic syntax and the common classes such
as Math, String, System.out,
Scanner, Basic file I/O, Stream.
Know the concept of Garbage
Collection, Reference Type (since
pointers are not available here.)
Know the Java platform/technologies,
J2SE, J2EE. Basic GUI with Swing and
its layout managers. Web
Applications with Servlet/JSP.
Popular tools, frameworks, and libraries: This may not as
important as above bullets. But
maybe you should know what Eclipse,
Netbeans, Spring, Struts, Hibernate,
EJB, Ant, JUnit, JavaDoc, are for.
You can always search for "C++ to Java" in Google. I'm sure there will plenty of good start points. Don't forget not to put * in front of var name next time you code Java :)

I recommend you read the book Effective Java cover to cover. Not only will you learn lots of good programming practices, but you will also learn more about Java than you otherwise would. Highly recommended. :-)
As a simple example, in Java, rather than rolling bitfields by hand (which is rather painful to do in Java, and for good reason), you use an EnumSet instead. This is documented in Item 32.
BTW, if you don't mind reading a PDF (no DRM) version, it's cheaper than hardcopy too: http://www.informit.com/title/0132345285

There are a number of great "in depth" Java books that will teach you not only Java, but also best programming practices.
If you're just interested in syntax and an introduction to the Class Hierarchy, Java in 24 hours is pretty good. From there, you will know enough to go and explore more on your own.
I highly recommend thinking of a small project to help you learn. In fact, think of a teeny tiny project -- it will turn out much bigger than you think! ;) Maybe a simple shoot-em-up or a Daleks- or Asteroids-alike, or some such.
The main thing being: for an expert-level programmer, don't try to learn Java from a book. You can get introduced to Java via a book, but then you have to go learn on your own (or from another.) It's like learning to drive a car -- you can get the basics from a book, but you need to explore & try stuff, and someone who knows how can be very helpful.
Some things that will help:
Download and bookmark the HTML Java docs. You will reference them often.
Have a small project, a simple game or utility app that you estimate will take a couple of days to write. Spend a couple of weeks writing it ;)
Note that "Java" is 3 things:
Java the programming language. Like C++ or Lisp or Perl.
Java the Class Hierarchy. Like STL or Cocoa.
Java the run-time virtual machine, the JVM.
People use the word "Java" to mean all 3 things, and slip between them without much notice, so pay attention to that, when you start talking Java to people.
Good luck!
(And let us know when your game is available :)

The biggest issue with the C++ to Java conversion is that they're so similar -- you'll find yourself doing C++-isms for a while. But it's no big deal: as suggested, read Josh Bloch's book, and run through the tutorials on java.sun.com and you'll do fine.

In my opinion, Java sets itself apart from C++ in three ways:
Automated memory management
Simplified syntax (and no preprocessor)
The Java standard libraries
As a former C++ guy, the first two shouldn't be a problem. (In fact, I would wager they will strike you as rather refreshing.) To get used to the libraries, I recommend Bruce Eckel's Thinking in Java - the 3rd edition is free to download. Though the beginning chapters will probably be a little too basic, the sections about GUI programming, concurrency, and the various container classes will be very helpful.
Beyond that, the best way to learn any language is to read good code.

I started by reading the Java Language Specification, version 2 at the time (2001).
In my view it is quite readable as specifications go.
Effective Java is good advice.
Java Puzzlers is good to learn corner cases and possible pitfalls.

The Peter Norton's Guide to Java Programming, "Making the Transition from C/C++ to Java".