quote:Original post by Khaos
Concerning the prospect of using C/C++/C#/Java style syntax (or something similar), I ask: why? Is it not the point of progress to try new things?
No.
MSN
angryzenmaster @ livejournal
Feedback on: a perfect programming language
No.
MSN
angryzenmaster @ livejournal
fodd3r, Dylan (mentioned above somewhere) is internally quite similar to Scheme, but has a C-like syntax. Take a look at it.
quote:Original post by msn12b
No.
Wow, an excellent response that is sure to prompt amazing responses like this one!
(Someone had to call him out. Either put some reasons up or shut up.)
Author
It''s fine that you responded with a negative answer, but simply saying "no" makes your post seem sarcastic and quite mean. Please, could you explain why? Or if someone else agrees, back him up with opinions and facts. Yes or no answers do not get us anywhere.
If one were to deviate from C-style syntax, what are some examples of aesthetically pleasing syntax? New and original syntax ideas would be interesting to share.
Also, could one invent new paradigms (like logical and object-oriented, et cetera) to solve new problems? Examples? I find it hard to start completely fresh. I think I''d be better at improving object-orientation, but creating a entirely original paradigm, like creating a new literature genre, seems to be a difficult task. But any ideas are welcome.
If one were to deviate from C-style syntax, what are some examples of aesthetically pleasing syntax? New and original syntax ideas would be interesting to share.
Also, could one invent new paradigms (like logical and object-oriented, et cetera) to solve new problems? Examples? I find it hard to start completely fresh. I think I''d be better at improving object-orientation, but creating a entirely original paradigm, like creating a new literature genre, seems to be a difficult task. But any ideas are welcome.
A Python-style core language with Lisp-like macros to extend it with new constructs.
[edited by - civguy on October 23, 2003 9:38:20 AM]
quote:Original post by MayrelDude.. That's truly ugly. And way too redundant.
For my toy language, I have documentation embedded as XML as so:import std.io.*;@<fun name="main" type="int"> <arg name="args" type="char[][]" text="Arguments"/> This program does blah, blah, blah.</fun>int main (char[][] args){ out.print(1 + @<note>This is seven, for no particular reason</note> 7); return 0;}
[edited by - civguy on October 23, 2003 9:38:20 AM]
What are the goals of the language? Portability? Can I write programs with it that run on mainframes and cell phones? General purpose or targeted problem space? Flexibility and power (and high level of responsibility) given to the programmer or safeguards built in to make it easier on them?
--
Dave Mikesell Software & Consulting
[edited by - dmikesell on October 23, 2003 9:35:06 AM]
--
Dave Mikesell Software & Consulting
[edited by - dmikesell on October 23, 2003 9:35:06 AM]
I can''t think of a perfect language (some features I like are inconsistent). Haskell''s type system plus context (i.e. the type class of a type variable) inferencing would be perfect, as far as I can see. The next best thing (and marginally better than Haskell as is) is dynamic, strong typing. If Python''s type system had interface checking (or interface invariance, if the language is functional), it would also be essentially perfect.
Some sort of layout semantics (like Haskell and Python have) are a must.
I don''t know if Haskell with more imperative constructs in its monadic sub-language would be better than any current offerings, but I''d certainly like to try such a thing. It''d probably be my choice for compiled programs, especially if it had an extremely smart compiler.
An IDE is not important, but an interactive interpreter on a language with lots of introspection capabilities (or with such introspection built into the interactive interpreter) is vital.
Some sort of layout semantics (like Haskell and Python have) are a must.
I don''t know if Haskell with more imperative constructs in its monadic sub-language would be better than any current offerings, but I''d certainly like to try such a thing. It''d probably be my choice for compiled programs, especially if it had an extremely smart compiler.
An IDE is not important, but an interactive interpreter on a language with lots of introspection capabilities (or with such introspection built into the interactive interpreter) is vital.
quote:Original post by Khaos
Is it not the point of progress to try new things?
Of course it is. Surely that's the very definition of progress?
quote:
Why create a new language that looks the same as C, uses the exact same paradigms (perhaps, only improved), and is different only in terms of a few new keywords?
Because people are familiar with it. To learn to code using an entirely new paradigm is incredibly difficult. What is better is if the language supports several related paradigms. Also C-style syntax is teh r0xX0rz
.quote:
Would anyone agree it might be time to think outside of all current paradigms? If not, explain why.
See above.
quote:
Secondly, how would one attempt creating a truly, fully, and easily portable language? What considerations would need to be detailed and included in the language, and how would it affect things?
Portable is trivial. If you want portable *and* efficient, on the other hand, things get more hairy. I'd say that the main issue is the representation of datatypes. C goes the correct route by not explicitly specifying the sizes or internal representation of types, instead specifying them in terms of their behavior , which allows for a lot of flexibility in how types are actually implemented. On the other hand, it's nice if you can rely upon a type being a particular size. So, what to do?
fodd3r: Exceptions are teh good, actually. But what are semi-predicates?
Icon rocks. Something I intended to touch on earlier is the notion of generators, and failure-based constructs.
Generators are special functions and operators which return values but can be resumed later to return further values. For example, in Icon find(s1,s2) returns the positions in which s1 appears in s2.
line := read() write(find("hello", line)) This example writes the position of "hello" in the first line of input, or nothing if it does not appear. Using the 'every' construct, the use of the generator becomes immediately obvious:
line := read() every write(find("hello", line)); Which writes all the positions within the input line at which hello occurs.
Failure is a useful concept. When part of an expression fails, the rest of the expression immediately fails -- no more of the expression is evaluated.
This can be combined with the usual 'while' construct to produce a simple text search program:
lineno := 0 while {line := read(); lineno := lineno + 1} do every write(lineno, ": ", find("hello", line)); This prints the line and column numbers of the occurances of "hello" in the input file. If find() fails (no occurances in the current line), then write() isn't evaluated, and nothing is output for that line.
[edited by - Mayrel on October 23, 2003 1:22:46 PM]
Mayrel:
Exceptions are teh suck,d00d.
My problem with them is that they''re too much like gotos. All of a sudden your code just starts going all over the place, all over my face. Yeah that sounds gross, because it exceptions are.
What are semi-predicates. Well this is where Icon, scheme, and other languages kick ass and take names. Basically, if you have things like expressions, then you have something better than semi-predicates but here goes.
Predicate: For this discussion some that evaluates to either true or false.
Semi-predicate: Half a predicate. I''m sure there are countless times where we write up some function where it returns an int > 0 on success and less than 0 or 0 on failure. Basically, a semi-predicate is this. Except the return value varies. You can return whatever the return is if the function goes through fine, if it doesn''t you could return false. Or you could return true if it works and some error code when it fails. These are much nicer than expressions, the value/failure model allows for more orthogonal error check code, vs the goto soup that exceptions create. I hate try catch blocks and wish to kick them in the nuts.
With expression based languages such as Icon you have either the last evaluated value returned OR you have a fail, which is inherited which is fricken sweet. Yes other languages do this.
Generatwhores are da bomb. However, there is an issues, it requires back tracking which if you''re a Erlang believer is bad for concurrent execution. The power of backtracking is too damn spiff to give up me thinks.
BTW, I think pass by value and pass by reference can be figured out via contracts so the compiler could do some nice optimisations.
Exceptions are teh suck,d00d.
My problem with them is that they''re too much like gotos. All of a sudden your code just starts going all over the place, all over my face. Yeah that sounds gross, because it exceptions are.
What are semi-predicates. Well this is where Icon, scheme, and other languages kick ass and take names. Basically, if you have things like expressions, then you have something better than semi-predicates but here goes.
Predicate: For this discussion some that evaluates to either true or false.
Semi-predicate: Half a predicate. I''m sure there are countless times where we write up some function where it returns an int > 0 on success and less than 0 or 0 on failure. Basically, a semi-predicate is this. Except the return value varies. You can return whatever the return is if the function goes through fine, if it doesn''t you could return false. Or you could return true if it works and some error code when it fails. These are much nicer than expressions, the value/failure model allows for more orthogonal error check code, vs the goto soup that exceptions create. I hate try catch blocks and wish to kick them in the nuts.
With expression based languages such as Icon you have either the last evaluated value returned OR you have a fail, which is inherited which is fricken sweet. Yes other languages do this.
Generatwhores are da bomb. However, there is an issues, it requires back tracking which if you''re a Erlang believer is bad for concurrent execution. The power of backtracking is too damn spiff to give up me thinks.
BTW, I think pass by value and pass by reference can be figured out via contracts so the compiler could do some nice optimisations.
quote:Because people are familiar with it. To learn to code using an entirely new paradigm is incredibly difficult. What is better is if the language supports several related paradigms. Also C-style syntax is teh r0xX0rz
Hardly. C syntax blows goats because it isn''t symmetric. Not to mention block defined by braces are useless.
Symmetry is wonderful if you''re going to do work on the actual language. But then you have to decide whether doing work on the actual language is good or not? Maybe it''d just be better to do work with the language to produce constructs rather than alter the language to achieve the same goal. Ease of implementation vs Ease of use/read/understand.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
