|
1. Full continuations (not just outward like Exceptions).
2. Proper lexical scoping (amazing how many languages cannot do this, including C#).
3. Proper tail recursion.
4. Syntactic abstraction.
Of course, Scheme offers all of these 
xacc.ideIronScheme a R5RS/R6RS-compliant Scheme on the DLR
The rule of three: "The first time you notice something that might repeat, don't generalize it. The second time the situation occurs, develop in a similar fashion -- possibly even copy/paste -- but don't generalize yet. On the third time, look to generalize the approach."
|
|
|
|
|
You sick, twisted, LISPing perverts and your parentheses.
Software Zen: delete this;
|
|
|
|
|
From the R6RS, Appendix E.
- Matched square brackets can be used synonymously
with parentheses.
xacc.ideIronScheme a R5RS/R6RS-compliant Scheme on the DLR
The rule of three: "The first time you notice something that might repeat, don't generalize it. The second time the situation occurs, develop in a similar fashion -- possibly even copy/paste -- but don't generalize yet. On the third time, look to generalize the approach."
|
|
|
|
|
leppie wrote: 2. Proper lexical scoping (amazing how many languages cannot do this, including C#).
It doesn't? Well, I guess I can agree with that. However I suspect it's not that it couldn't, but that "they" decided to compromise.
|
|
|
|
|
<font color="Teal">Func</font><font color="DarkBlue"><</font><font color="Blue">int</font><font color="DarkBlue">,</font> <font color="Blue">bool</font><font color="DarkBlue">></font> odd <font color="DarkBlue">=</font> x <font color="DarkBlue">=></font>
<font color="DarkBlue">{</font>
<font color="Teal">Func</font><font color="DarkBlue"><</font><font color="Blue">int</font><font color="DarkBlue">,</font> <font color="Blue">bool</font><font color="DarkBlue">></font> oddi <font color="DarkBlue">=</font> <font color="Blue">null</font><font color="DarkBlue">;</font>
<font color="Teal">Func</font><font color="DarkBlue"><</font><font color="Blue">int</font><font color="DarkBlue">,</font> <font color="Blue">bool</font><font color="DarkBlue">></font> eveni <font color="DarkBlue">=</font> y <font color="DarkBlue">=></font> y <font color="DarkBlue">==</font> <font color="Red">0</font> <font color="DarkBlue">?</font> <font color="Blue">true</font> <font color="DarkBlue">:</font> oddi<font color="DarkBlue">(</font>y <font color="DarkBlue">-</font> <font color="Red">1</font><font color="DarkBlue">)</font><font color="DarkBlue">;</font>
oddi <font color="DarkBlue">=</font> y <font color="DarkBlue">=></font> y <font color="DarkBlue">==</font> <font color="Red">0</font> <font color="DarkBlue">?</font> <font color="Blue">false</font> <font color="DarkBlue">:</font> eveni<font color="DarkBlue">(</font>y <font color="DarkBlue">-</font> <font color="Red">1</font><font color="DarkBlue">)</font><font color="DarkBlue">;</font>
<font color="Blue">return</font> oddi<font color="DarkBlue">(</font>x<font color="DarkBlue">)</font><font color="DarkBlue">;</font>
<font color="DarkBlue">}</font><font color="DarkBlue">;</font>
<font color="Teal">Console</font><font color="DarkBlue">.</font>WriteLine<font color="DarkBlue">(</font>odd<font color="DarkBlue">(</font><font color="Red">10</font><font color="DarkBlue">)</font><font color="DarkBlue">)</font><font color="DarkBlue">;</font>
xacc.ideIronScheme a R5RS/R6RS-compliant Scheme on the DLR
The rule of three: "The first time you notice something that might repeat, don't generalize it. The second time the situation occurs, develop in a similar fashion -- possibly even copy/paste -- but don't generalize yet. On the third time, look to generalize the approach."
|
|
|
|
|
Automatic memory management is nice, but I think it's important that a language provide help in managing other resources as well.
Nathan
|
|
|
|
|
Nathan Holt at EMOM wrote: Automatic memory management is nice, but I think it's important that a language provide help in managing other resources as well.
Hear, hear!
|
|
|
|
|
Not survey items, but two things none the less:
I am unable to find the vote page. My usual link (that used to work) now fails:
http://www.codeproject.com/script/survey/feedback.asp
So, thing one is 'how do I get to the survey voting page?
Thing two is, at least, relevant. In this case, I'm glad I didn't get to the vote page. For a change, when given a chance to think before voting (no, I didn't vote for "W" - ever) I realized that I'd never really considered what I want in a programming language. I moved from R-M Fortran to MS QuickC because I needed graphics routines, but that's part of almost every package these days.
Primarily, it's more a crude thought: will the language do what I want to do when I want to do it? In the good old days, C gave me absolute access to everything. Now, this is no longer a 'given'. I've sold even more of my soul by embracing .NET. So many paradigms of old have faded: speed, efficiency, size of executable image have been usurped by the paradigm of eye-candy.
But the audience has changed so much - perhaps this is as it should be. I'll simply accept my fate and fade off into a forgotten past. Endlessly mulling over just what is it that causes me to prefer one language over another - and what would induce me to switch.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
|
|
|
|
|
Is "Industry acceptance as a "standard" language", considered a feature of a language?
Why?
And what this option has to do with the rest options of that survey?
All the rest seem strictly technical to me.
So, there are two views into those survey options:
A marketing view, represented by that single "acceptance" option
and a technical view represented by the rest of the options.
That is a) find a job and b) do the job (lol)
Just my thoughts
Regards
Theo
--------------------
Theo Bebekis
Thessaloniki, Greece
|
|
|
|
|
Theo Bebekis wrote: Is "Industry acceptance as a "standard" language", considered a feature of a language?
Why?
Yes. Primarily for reuse, and retraining issues. Do you write in Slip? have you even heard of Slate? Sloop? Spitball? SpeakEasy? There have been hundreds of languages and they come and go like the seasons. Why? Because they don't get the industry support. A language that gains industry standardization gets widespread use, gains training advantages, and support advantages. The reasons to have a standards compliant language is exceedingly large. But, primarily, from a future perspective, you protect the investment of your own time and money by using industry acceptance and standards compliance based languages.
And remember: "Sail" your way around problems, be "Sure" of your language choices and throwing "Sticks&Stones" may not achieve what you "Hope" to do.
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
It's quite nice to have the source code of the api available too.
|
|
|
|
|
ed welch wrote: source code of the api
Looks like two entities got merged in this phrase.
(1) Source Code
(2) API and Heterogeneous Application Interoperability
Wouldn't the division make your stand clear?
Vasudevan Deepak Kumar
Personal Homepage
Tech Gossips
A pessimist sees only the dark side of the clouds, and mopes; a philosopher sees both sides, and shrugs; an optimist doesn't see the clouds at all - he's walking on them. --Leonard Louis Levinson
|
|
|
|
|
Open Source is good. Without that, no progress in the programming world would be possible.
However, the way I see it is that: you don't have time and resources to do everything. So you choose: You either become a programming language developer (in that case having the source code is...neccessary!) or you develop applications based on that language (in that case having the source code is nice, but not so neccessary...).
I belong in the second category. I like to know how things work, so yes - I would look at the source code to learn the inner workings of C++ for example. But wouldn't spend days on that... 
|
|
|
|
|
Doesn't matter weither you are an application developer, or not, having the source code is always an advantage.
Sometimes understand to what a function is doing it's easier seeing the code than reading the documentation
Also when debugging you can step into the api functions and see what's going on (that was a part of MFC that I liked)
Extending api functionality is easier too. You can modify the existing source code.
|
|
|
|
|
Vasudevan Deepak K wrote: Heterogeneous Application Interoperability
Holy crap! 
|
|
|
|
|
This survey seems to be multiple choice one but there has been no option for 'Text Answers' (Optional Text Answers).
BTW, I was looking out for this to bring in the classic omnipotent and omnipresent CListCtrl. 
Vasudevan Deepak Kumar
Personal Homepage
Tech Gossips
A pessimist sees only the dark side of the clouds, and mopes; a philosopher sees both sides, and shrugs; an optimist doesn't see the clouds at all - he's walking on them. --Leonard Louis Levinson
|
|
|
|
|
Multiple choice does not imply free text answer.
cheers,
Chris Maunder
CodeProject.com : C++ MVP
|
|
|
|
|
Wouldn't the following points very much Paradoxical?
1) Compile to native code [no intermediate or byte code]
2) Cross Platform Support
Or if the SDK has to give this feature, its toolset should be really very versatile and rich collection.
Vasudevan Deepak Kumar
Personal Homepage
Tech Gossips
A pessimist sees only the dark side of the clouds, and mopes; a philosopher sees both sides, and shrugs; an optimist doesn't see the clouds at all - he's walking on them. --Leonard Louis Levinson
|
|
|
|
|
Not at all. Programming language features are attributes of the source code after all. For the purposes of this discussion, I don't think the compile/link requirements or target environment are the primary concerns.
For example, look at C++. It satisfies both of the requirements of native code compilation and supporting cross platform development. Compare that to assembly language, which obviously meets the native code constraint, but isn't cross platform capable.
Software Zen: delete this;
|
|
|
|
|
Apart from what Gary says, Eiffel also satisfies both 1 and 2.
Kevin
|
|
|
|
|
Nope, not paradoxical, but rather dependant on industry support (making compilers).
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
