One of the first exercises in Software Abstractions is to convert example properties from the relational calculus style to the predicate calculus style.
Despite studying the Logic chapter in the book i still can't confidently say which is and which isn't an example of the predicate, navigation expression and relational styles.
Any advice appreciated
You've asked for advice, and not for a definition of the three styles of expression. My advice is: don't worry about it.
I've been using Alloy for years now, and I can't remember ever running into any problem whose solution depended on the distinction. You can think of the discussion in Software Abstractions as a way of making clear some of the ways in which Alloy offers more than one way to express the same idea, and using names to make clear that in crucial ways it's an intentional property of the language design, not an accident.
If you're writing Alloy for a group project, it may matter which style you pick at any moment; if you're writing for yourself, you could do worse than write things down in whatever way makes clearest to you what the expression is doing (and makes it easiest to tell that you've got the expression formulated correctly).
Don't be disheartened. As Michael Sperberg-McQueen explains, it's not essential and you should just not worry and move on. I put this in the book to explain to people coming from different logical backgrounds how Alloy could be used in a style they were familiar with: the predicate style for people familiar with traditional first order logic; the navigational style for those familiar with writing runtime assertions in languages like Java, and with OCL; and the relational style for those who had seen Z. For those unfamiliar with these, that section turned out to be quite unenlightening!
Related
I recently saw a programming language called supernova and they said in the web page :
The Supernova Programming language is
a modern scripting language and the
First one presents the concept of
programming with direct Fiction
Description using
Clear subset of pure Human Language.
and you can write code like:
i want window and the window title is Hello World.
i want button and button caption is Close.
and button name is btn1.
btn1 mouse click. instructions are
you close window
end of instructions
my question is not about the language itself but it is that are we need such languages and did they make writing code easier or not?
The code may look like natural language, but it's really just regular computer code with different keywords. In your example, I want is probably synonymous with new. It's not like you can use natural language directly and say make me a window instead (and if you could, things would get even uglier...).
Lets take a close look at your code and the language implications:
i want window and the window title is Hello World.
i want means new, and denotes beginning of the argument list. the <type_name> <member_name> is sets instance variable member_name on the object being created. Note that you have to write the type_name twice.
i want button and button caption is Close.
and button name is btn1.
. ends a statement. However, you can 'chain' method calls on an object by starting the next statement with and. Also, how do you refer to a variable named Close instead of the string "Close"? Heck, we even have this problem in regular English: what the difference between 'Say your name' and 'Say "your name"'?
btn1 mouse click. instructions are
you close window
end of instructions
mouse click is an identifier containing a space, should be mouseClick. instructions are defines a lambda (see the is vs. are keyword confusion causing trouble yet?). you close window calls window.close(). end of instructions is end of a lambda. All of these are longer than they need to be.
Remember all that? And those are only my guesses at the syntax, which could be completely wrong. Still seem simple? If so, try writing a larger program without breaking any of those rules, AND the additional rules you'll need to define things like conditional logic, loops, classes, generics, inheritance, or whatever else you'll need. All you're doing is changing the symbols in regular programming languages to 'natural language' equivalents that are harder to remember, unnecessarily verbose, and more ambiguous.
Try this translation:
var myWindow = new Window( title="Hello World" );
myWindow.addButton( new Button( caption="Close", name="btn1" ) );
btn1.onMouseClick = function() {
myWindow.close();
}
See how each line maps to its counterpart in the previous example, but states the intent more directly? Natural language may be good for execution by humans, but it is terribly difficult to use for precise specifications.
The more you try to make English communicate these ideas easily and clearly, the more it's going to look like programming languages we already have. In short, programming languages are as close to natural language as we can get without losing clarity and simplicity. :D
Since the fundamental difficulty of programming is getting your thoughts ordered enough to tell the computer what to do, making the language more “natural” is highly unlikely to make it more accessible to non-programmers; the language itself was never the real problem in the first place. What's more, all that extra clutter of natural language doesn't help any programmers (worth the name) with what they're doing either, so why add it?
Or can we have a real natural language programming language, complete with “Um”, “Er”, and “Oh, I don't really know”? :-)
Edsger W. Dijkstra, On the foolishness of "natural language programming". I have nothing to add.
The programming language you have showed us above is extremely verbose (as it seems even more than COBOL).
This comes with several problems:
It takes long code to do simple things.
Code grows unmaintainable fairly fast
It takes long to find out what code does
Whether they're better or not is opinion, but that looks like some mutated cross of COBOL and BASIC, which is most definitely epically bad.
So in my opinion, no. I think somewhat to-the-point languages that still use readable verbs/adjectives/names are better (C++, C#, PHP, etc are my preferred languages).
Some languages start to get too high-level and/or verbose, making the actual logic so abstracted it's hard to know what does what. Some are too low-level and brief, forcing you to explicitly state everything you want done. A balance between readability and brevity, with power and flexibility, is what is best for development.
I'll be brave and offer a slightly different opinion here.
I haven't seen anything of this language other than what has been presented in the question, but looking at that I'd have to say it probably is much more readable for a non-programmer. For a programmer on the other hand it won't hurt readability, but it won't help either because we're used to reading code.
On the actual development side of things, I think it would be horrible to have to type so many extra bits especially if you're used to succinct keywords and constructions like us programmers.
But let's imagine a far away future where speech recognition is actually accurate. I think a language like this would be far easier to code by talking to your computer, I'd hate to have to specify every parenthesis and such. Not having to do that would help keep your train of thought.
In conclusion:
non-programmer readability: great.
programmer readability: no improvement.
codability typing: no, just...no.
codability speech: probably much easier.
person.eBusiness[text.this.author].like(language.supernova.idea.reverse);
language.English[ambiguous[very]];
person.eBusiness.suggest(create(language.Codetalk));
language.Codetalk.grammar.inspiration=language.programming.grammar;
language.Codetalk[new,better,ambiguous[not]];
if(person.all.use(language.Codetalk)){
person.all.understand(person.all.communication);
};
question(language.Codetalk.idea[good]);
In my opinion there is no really useful advantage in using that kind of "human language", because you still need a syntax and special words. You have to learn both of them, and because that's necessary it would be not much more difficult to learn a "programming language", which gives lots of advantages because it is oriented at the machine's structure and not at the human's way of thinking.
You will need to think the way the machine works if you want to write good programs, and a programming language is definitely more powerful to express that way of thinking than human language.
One problem with these languages is: Say you write significant portions of your app in this language and then need different people to maintain,extend or otherwise change the code.
Who are you going to get to do this ? Nobody off the street is going to know it and others are going to have a steep learning curve.
Let's also assume you have a question on how to accomplish a task the language, where do you turn ?
Well the perfect programming language would be an exact copy of the English Language. You could just tell your computer to do some stuff in the same way you might order a coffee or give homework to your class. However, such a language would be extremely difficult to implement (an advanced A.I would be necessary).
Somewhere some guy said (I honestly do not know where I got this from), that one should learn one programming language per year. I can see where that might be a good idea, because you learn new patterns and ways to look at the same problems by solving them in different languages. Typically, when learning a new language, I look at how certain problems are supposed to be solved in that language. My question now is, what, in you experience, are good, simple, and clearly defined tasks that demostrate the differences between programming languages.
The Idea here is to have a set of tasks, that, when I solve all of them in the language I am learning, gives me a good overview of how things are supposed to be done in that language. I do not know if that is even possible, but it sure would be a useful thing to have.
A typical example one often sees especially in tutorials for functional languages is the implementation of quicksort.
Search for "Code Kata" for some resources.
Pick a problem. Solve it in different languages.
http://slott-softwarearchitect.blogspot.com/2009/08/code-kata-resources.html
In today's world, I don't think simple tasks like implementing a bubble sort will really give you a taste for that language. The reason being that several of them have C at their core (java, c#, php, javascript, etc).
Instead, go for small apps like a simple contact manager. This will allow you to work with the chosen language's UI, Database, and logic features.
I've designed some educational programming languages and interpreters for them, but my problem always was that they ended up "normal" and "boring", mostly similar to some kind of existing language (ASM and BASIC).
I find it really hard to come up with new ideas for syntax features, "neat things" and new or very modified programming paradigms for it. I always thought that it was hard to come up with good new things not fun/useless new things for this case.
I wondered if you could help me out with your creativity:
What features in terms of language syntax and built-in functions as well as maybe even new paradigms can I work into my language to keep it useless but more fun, enjoyable, interesting and/or different to program in?
I always thought that it was hard to come up with good new things
You were right. This is why John Backus, Ken Iverson, Niklaus Wirth, Robin Milner, Kristen Nygaard and Ole-Johan Dahl, Alan Kay, and Barbara Liskov all won Turing Awards—they contributed good new ideas to the design of programming languages.
If you want to add a dash of interest to your own designs, these are excellent people to steal from.
Both ASM and BASIC are imperative languages, so you might want to consider features of functional programming languages, especially lambdas and maps. You might also want to consider interesting flows of control, for example, being able to throw an exception and then later, as a result of catching the exception and making a certain call, resume from the point that the exception was thrown (albeit using a modified environment). Also, co-routines, or other forms of language-level parallelism are often interesting.
In addition to Michael's comment on functional languages, look at closures and blocks (like they're done in Objective-C). Those let you treat functions or pieces of code as first-class objects that you can pass around and call on demand. Some cool stuff can be done with that, and it's also shaping up to becoming the paradigm for programming massively multi-core systems.
You could also look into currying, which means binding some of a function's parameters, so you can then use it on fewer arguments. That way, you could create a base-b logarithm function, which you could curry to create functions for the base-2, base-10, etc. logarithm.
And something less functional (as in language): look at Ruby's way of treating everything as an object (even numbers), you can do quite a bit with that. Like an object-oriented runtime with introspection, an interpreter "for free," etc. Implementing OOP stuff is easier than you'd think.
A lot of stuff has been done in the last 30-odd years, don't restrict yourself to 70s-style programming! ;) If you're looking for inspiration, check out Ruby, Python, Scala, Objective-C, JavaScript (read Douglas Crockford's JavaScript: The Good Parts), etc.
The Esolang wiki gives a good sample of the weirds and wonderfuls of all kinds of esoteric programming languages, including many user creations. Perhaps some inspiration for something sane lies therein.
look at Forth. It is something original. Too original.
intercal has plenty of unusual language features B-)
I've always thought it would be neat to apply CSP to a stack based language. Could get pretty interesting.
See Wikipedia: Programming Languages. There are many useful links, especially in the Taxonomies section.
So much of the "new" is really just "forgotten old". I will hold my thoughts on some of the "popular" programming languages of the day.
There are many things that could be explored and active research is being done on some of them. Some of the things I think would be useful are:
real continuations in a non-functional language
here is an attempt to add them on to C++: http://mainisusuallyafunction.blogspot.co.nz/2012/02/continuations-in-c-with-fork.html
languages that let the user create new syntax elements
FORTH and J might be starting points.
Pogoscript is interesting as well because flow control constructs like if/elseif/else and while/wend arten't special can be created in user code.
custom user defined operators actually aren't new: I think Haskell, Nemerle, Kaleidoscope and several others already do this but even that wouldn't be "boring"
Jon Skeet posted this blog post, in which he states that he is going to be asking why the dynamic part of languages are so good. So i thought i'd preemptively ask on his behalf: What makes them so good?
The two fundamentally different approaches to types in programming languages are static types and dynamic types. They enable very different programming paradigms and they each have their own benefits and drawbacks.
I'd highly recommend Chris Smith's excellent article What to Know Before Debating Type Systems for more background on the subject.
From that article:
A static type system is a mechanism by which a compiler examines source code and assigns labels (called "types") to pieces of the syntax, and then uses them to infer something about the program's behavior. A dynamic type system is a mechanism by which a compiler generates code to keep track of the sort of data (coincidentally, also called its "type") used by the program. The use of the same word "type" in each of these two systems is, of course, not really entirely coincidental; yet it is best understood as having a sort of weak historical significance. Great confusion results from trying to find a world view in which "type" really means the same thing in both systems. It doesn't. The better way to approach the issue is to recognize that:
Much of the time, programmers are trying to solve the same problem with
static and dynamic types.
Nevertheless, static types are not limited to problems solved by dynamic
types.
Nor are dynamic types limited to problems that can be solved with
static types.
At their core, these two techniques are not the same thing at all.
The main thing is that you avoid a lot of redundancy that comes from making the programmer "declare" this, that, and the other. A similar advantage could be obtained through type inferencing (boo does that, for example) but not quite as cheaply and flexibly. As I wrote in the past...:
complete type checking or inference
requires analysis of the whole
program, which may be quite
impractical -- and stops what Van Roy
and Haridi, in their masterpiece
"Concepts, Techniques and Models of
Computer Programming", call "totally
open programming". Quoting a post of
mine from 2004: """ I love the
explanations of Van Roy and Haridi, p.
104-106 of their book, though I may or
may not agree with their conclusions
(which are basically that the
intrinsic difference is tiny -- they
point to Oz and Alice as interoperable
languages without and with static
typing, respectively), all the points
they make are good. Most importantly,
I believe, the way dynamic typing
allows real modularity (harder with
static typing, since type discipline
must be enforced across module
boundaries), and "exploratory
computing in a computation model that
integrates several programming
paradigms".
"Dynamic typing is recommended", they
conclude, "when programs must be as
flexible as possible". I recommend
reading the Agile Manifesto to
understand why maximal flexibility is
crucial in most real-world
application programming -- and
therefore why, in said real world
rather than in the more academic
circles Dr. Van Roy and Dr. Hadidi
move in, dynamic typing is generally
preferable, and not such a tiny issue
as they make the difference to be.
Still, they at least show more
awareness of the issues, in devoting 3
excellent pages of discussion about
it, pros and cons, than almost any
other book I've seen -- most books
have clearly delineated and preformed
precedence one way or the other, so
the discussion is rarely as balanced
as that;).
I'd start with recommending reading Steve Yegge's post on Is Weak Typing Strong Enough, then his post on Dynamic Languages Strike Back. That ought to at least get you started!
Let's do a few advantage/disadvantage comparisons:
Dynamic Languages:
Type decisions can be changed with minimal code impact.
Code can be written/compiled in isolation. I don't need an implementation or even formal description of the type to write code.
Have to rely on unit tests to find any type errors.
Language is more terse. Less typing.
Types can be modified at runtime.
Edit and continue is much easier to implement.
Static Languages:
Compiler tells of all type errors.
Editors can offer prompts like Intellisense much more richly.
More strict syntax which can be frustrating.
More typing is (usually) required.
Compiler can do better optimization if it knows the types ahead of time.
To complicate things a little more, consider that languages such as C# are going partially dynamic (in feel anyway) with the var construct or languages like Haskell that are statically typed but feel dynamic because of type inference.
Dynamic programming languages basically do things at runtime that other languages do at Compile time. This includes extension of the program, by adding new code, by extending objects and definitions, or by modifying the type system, all during program execution rather than compilation.
http://en.wikipedia.org/wiki/Dynamic_programming_language
Here are some common examples
http://en.wikipedia.org/wiki/Category:Dynamic_programming_languages
And to answer your original question:
They're slow, You need to use a basic text editor to write them - no Intellisense or Code prompts, they tend to be a big pain in the ass to write and maintain. BUT the most famous one (javascript) runs on practically every browser in the world - that's a good thing I guess. Lets call it 'broad compatibility'. I think you could probably get a dynamic language interpretor for most operating systems, but you certainly couldn't get a compiler for non dynamic languages for most operating systems.
What features could be added to a new programming language
to make it more "intuitive"? When it comes to websites and
desktops, we favor high usability, almost intuitive
usability. It is becoming increasingly expected that your
application should "just work". For a certain class of
applications the idea that one has to RTFM, is a mark
against the effectiveness of the application. People tend to
expect the application to just work the way they "think" it
should work. One could argue that this is a worthy standard
that designers should strive for.
Can the same usability rigor apply to programming languages
and developer environments? I realize there are tools like
IntelliSense that provide hints, and a good IDE provides a
lot of assist. But what about the core language itself? What
could be added (or removed) that makes certain programming
techniques or algorithms more obvious to implement? How does
one make regular expressions or recursion more intiutive? Or
is this just folly?
Take a more concrete example: liquid layouts in HTML, CSS,
or Flex and MXML. In HTML and CSS, the box model is anything
but intuitive given the different implementations of
Internet Explorer and the other browsers. And unless someone
reads the documentation or studies the concept of the box
model it would be difficult to "just get it" when designing
a layout on one's first stab at CSS. I would argue this is
why tables thrived in the early days. The box model was
implicit in the concept of a table cell. With the help of
tools like Dreamweaver one could get their mind around
percentage widths and layout within the constraints of table
cells. Then CSS came into maturity and a whole set of valid
reasons emerged for why tables are not for layout. But to
achieve the same effects designers had to really study the
CSS implementations and the box model, and inject a new
layer of abstraction into their thinking.
In another example, I find when programming lots of things
in ActionScript and MXML, the whole concept of fluid layouts
and percentage based widths of elements not very obvious and
doesn't always follow intuition. I understand the basic
problem in that the Adobe Flash player and the layout need
to understand things in absolute pixel terms. When it comes
to the potential width of a component, I understand why
percentages are not immediately obvious to implement at the
core level of the code. Theoretically speaking the Flash
Player needs to know (or calculate) the exact width of a
component so that it can provide the proper geometry to the
video card when doing a draw on the screen. But when you
introduce some concept of percentages then you introduce the
theoretical possibility of an infinite width. And to find
"infinity - 1" pixels is not something a computer can
directly do without some layer of abstraction and
calculation. The viewport must be referenced. The program
must know its boundaries. So absolute widths are the norm,
although humans might prefer to design in terms of
percentages.
When it comes to programming languages can there be
expressions and features that assist intuition when thinking
about a programming task. Or are we better off "thinking
like a computer" and just RTFM'ing the manual when we need
to understand how to implement some feature or layout in
code?
If you could change the syntax or semantics of your
programming language of choice what would you add, change,
or remove to improve the "intuitiveness" of it?
Addendum, the reason for asking this question is inspired by
seeing example of what "novices" were able to achieve in
Smalltalk in Alan Kay's lecture: Doing with Images Makes
Symbols.
"If you could change the syntax or semantics of your programming language of choice what would you add, change, or remove to improve the "intuitiveness" of it?
"
Programming is hard. Really hard. Syntax changes don't matter much. IDE's are irrelevant to the fundamental challenge of programming.
The thing that is often baffling is the semantics of the language.
I don't know what "intuitive" means with respect to a thing as abstract as a programming language. Indeed, "intuition" is probably a bad thing. Coming to a programming language with intuition means preconceived notions, biases and intellectual junk will take over.
I would never expect to "just get it" for anything on any level anywhere. Programming requires clear thinking -- not "intuition" -- not "expectation".
The only thing we can ever do is read the manual and understand the unique, distinct, novel semantics of the new thing we're confronted with.
I do know this: elegant simplicity is essential. Orthogonality of features. Clarity. Precision. Absence of exceptions or special cases. Above all, simplicity.
Layering on language features is fundamentally bad.
Covering language problems by layering in a complex IDE is worse.
See http://www.cs.utexas.edu/~EWD/transcriptions/EWD08xx/EWD854.html
"when faced with something new and unfamiliar we try to relate it to what we are familiar with. In the course of the process we invent the analogies that enable us to do so.
It is clear that the above way of trying to understand does not work too well when we are faced with something so radically new, so without precedent, that all analogies we can come up with are too weak and too shallow to be of great help. A radically new technology can create such circumstances and the wide-spread misunderstanding about programming strongly suggests that this has happened with the advent of the automatic computer. "
In short, "intuition" and "intellectual baggage" is the problem of the programmer. The best way to understand a technology is to approach it as something fresh, new and otherwise unknown.
Bottom Line.
The complexity is inherent.
You have two choices.
Develop intellectual tools (i.e., abstraction, summarization, etc.) to cope with it.
Get a job in another field.
Asking for the inherently complicated world of computing to morph into something any one person finds "intuitive" can't happen. Computing is too complicated to be "intuitive".
Another field I've seen that addresses the complexity of the "syntax" of a programming languages is that of Visual Programming Languages. The basic idea behind VPLs is to take the constructs of programming languages (decisions, subroutines, functions, etc.) and represent them graphically, typically as a data-flow diagram. One such language that's gaining popularity recently is the Microsoft Visual Programming Language. I have not used it, and cannot make claims as to its power, but I have used LabView to great effect and I can say that you can do pretty much anything you can think of even in LabView -- but you do have to think of it in a very different way.
That said, I find I have a personal preference for code rather than VPLs.
One step folks are taking that has as much to do with base class library as it does the language itself -- although to be honest, the two are often synonymous -- is the concept of a Fluent API. The basic idea is to make code "read like a sentence", the idea being that this makes the code more flexible and maintainable.