nehaa arora

Greenhorn
+ Follow
since Oct 27, 2009
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
1
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by nehaa arora

Hi Burk,

Yes i agree..its more like programming for any other solution DSLs are not a different problem in that regard. A programming language helps in ease of development but no more than a good knowledge of the language tool.

Thanks,
Neha
Many thanks to Prof Parr and also to Burt and other contributors for making DSLs better explained.

regards,
Neha
Burk,

Quite agreeable. In the same line of thought, I assume language features more than a rich api would support DSL development better. And even to have an intermediate knowledge of Java one would need to be well versed with the language features ( though they keep on adding more as they did with enums for java 5 - quite nice!). I have a very vague feeling as to constructs like closures in a language are way more handy tools than probable roadblocking ones like Generics (in Java) as they are not so elegant in their behavior (is this my inexperience speaking?! ) This takes me back to Terrence's comment

I remember a friend, who was designing a new programming language, telling me about a bug he had in his parser. It allowed what he thought was a cool language feature. It was a weird special case. Every tool that parsed that language would have to have a bug to match it.



So here I am bothered about corner cases in my development language. I guess, then, the choice of language used for coming up with a DSL does have a bearing on its working and success. Thoughts?

Thanks,
Neha
Burk,

IMHO Java as is a very bloated language with umpteen features, which one could pick and choose to use. While designing a DSL, we would need to have a more focused set of language features.As Terrence advised we'd need to pick pretty features that fit the context from across languages (procedural/functional/object oriented/etc), moving beyond the language of implementation (though the language itself could show limitations as discussed here). And I surely agree with you in that the unix model would be a neat way to model a DSL on.


Thanks,
Neha

David Newton wrote:Closures are the biggest thing missing. The pomp and circumstance of Java also make things rather ugly when compared to other languages that allow a more natural internal DSL.

Java's shortcomings are well-documented; rather than continue this thread's spiral into forum-inappropriate chatter I'll just direct you to the web :)




Dunno if I am adding to the 'chatter' here..but i guess it would be real helpful to enlist imperative language features amenable to DSL development, as 'closures' were mentioned here. Does it then make more sense to pick a programming language suited for DSL work than build up sophisticated language frameworks in java .

thanks,
Neha

Terence Parr wrote:
Yep, experience helps in two ways: knowing when to go DSL and being able to get their quickly. It also helps in designing the language (syntax/semantics)...so three ways.

I cringe when see of the languages out there. I remember a friend, who was designing a new programming language, telling me about a bug he had in his parser. It allowed what he thought was a cool language feature. It was a weird special case. Every tool that parsed that language would have to have a bug to match it.



Hmm...any hints as to how one can attain nirvana here? I know nothing beats making your mistakes and learning from them but a guru can sure set one on the right path to the needed grind. Any recommended references for the above three, besides your book?

Thanks,
Neha

Terence Parr wrote:

Burk Hufnagel wrote:even something like a RESTful web service could be considered a small and rather limited DSL.



Sure. Anything that is not random text follows the format, hence, a language. URLs certainly follow a language. The output of the Web service itself must also follow a format. This is usually XML or JSON etc... Those are languages.

When your world is a parser generator, everything looks like a parsing problem ;)



Wow! that is indeed an interesting view to problem solving! but it would need a lot of experience to know you are not hammering down your screws?!

Neha
Yes Burk, that sounds quite right

thanks,
Neha
Burk,

I share your view on the plus of pluggable application framework. I intended to use 'limiting' in my question to mean if i am viewing the DSL application domain, wholly or just an aspect (ie. creating application architectures that support pluggability).

Hi,

I am getting a feel for DSL through the discussions since yesterday. If i am getting it right DSLs are more about the idea of kernel application with pluggable utilities/services. Is this a limiting view?

Further, aren't DSLs a huge undertaking in terms of maintainability and usability?

thanks,
-Neha
Hello Prof. Parr!

What computer language fundamentals are required to get on with building/designing a DSL beyond the ones required for writing 'theoretical' compilers?
Thanks!
Hi,

Could someone please share info non-Sun certifications like the ones from IBM. Where do those fit in?

Thanks,
Neha
Congrats Neha!

Being your namesake, I am trying to repeat the feat soon! Especially admire your active contribution to the forum.

Thanks,
Neha
14 years ago

Abimaran Kugathasan wrote:I'm late and I've doubt in this code.
1) What is the neediness for the import java.util.*; statements?
2) Why is this program doesn't terminate normally?



Yea i too second that the import statement is unnecessary here.

The program would not terminate properly as each thread is waiting while never being notified at all. Please correct me if I am wrong here.

thanks,
Neha