|
Except for the interpreted part, it sounds like C/C++, but you need to use a modern compiler that whines about things like assignments in ifs (or maybe do a lint pass) and a modern IDE for it.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
|
Whenever I read one of these "desires to fix programming languages", I laugh. I have been programming since the 80's and I too went through that phase right after college.
However, I never had to work with all these silly pseudo-languages that come and go. We used ASM and C. Then Byorn Stroustroup (?) comes along and says, "hey, I hate programming, I'll add a bunch of junk to keep myself from making mistakes." I would've suggested he find a new line of work instead. C++ is a mess. It's poorly conceived, coerced and unnatural. It does nothing that a professional programmer can't accomplish in plain old C. As is usually the case, it causes more problems than it fixes, or it fixes one set but creates another set.
Considering that most of the world is embedded micro-controllers, those of us who program them don't have gigabytes of memory or gigahertz processors as we need to be more efficient. Over 20 years this has taught me to appreciate C and ASM more. I'm glad I never got my wishes to have a bullet-proof language.
I suggest if you're having issue with a particular part of a language, create a preprocessor directive and use it!
For example, if your problem is:
if (x = y)
this can be fixed by defining:
#define IS_EQUAL ==
then used everywhere as:
if (x IS_EQUAL y)
No need to suggest the world change, or hope someday this 'gets fixed' for you. The C preprocessor is probably the most overlooked part of C. You can easily invent an entirely new language using the preprocessor.
In fact, Linus Torvalds, who is a pretty awful programmer, took to using the preprocessor in ways most professionals would recommend against. But he recognized that it could keep him from repeating certain mistakes he tended to make.
|
|
|
|
|
|
Indeed, SmallTalk ! I suspect many of the newly-minted prophets-with-visions on this thread would gasp if they knew what SmallTalk was capable of in 1968, and what software development tools were like at Xerox PARC at that time.
Of course, the expen$ive hardware needed to run SmallTalk was not available to mere mortals.
“I'm an artist: it's self evident that word implies looking for something all the time without ever finding it in full. It is the opposite of saying : ‘I know all about it. I've already found it.’
As far as I'm concerned, the word means: ‘I am looking. I am hunting for it. I am deeply involved.’” Vincent Van Gogh
|
|
|
|
|
rjmoses wrote: trace their origins back to the days when terseness was a desirable quality.
First, compilers (of which interpreters are just a subset) have deterministic requirements that cannot and should not be circumvented. Thus certain language constructs exist to insure that there is no ambiguity. And this is a feature of compilers (specifically compiler theory) and not just some misunderstanding by the author of the language.
Second, terseness serves another need in that communications requires one to transfers thoughts to the computer. Increasing the verbosity would decrease the rate at which that can occur.
Third one must be aware that no language can be perfect and no user of that language can be perfect either thus the compiler must strive to report errors to the best of its ability. At least in my experience doing that is one of the hardest parts of writing a compiler.
Fourth languages are meant to serve different purposes and no one language can meet the needs of all possible uses without adding complexity that circumvents the original desire for simplicity.
rjmoses wrote: Among other things, a New Programming Language should:
There are a large number new programming languages created every year and presumably many start with the idea that they are going to be 'better' than what already exists.
Many, many, fail to achieve that goal. So many that one can bet that not even one language introduced within one year will ever achieve anymore than a very, very small niche (even that is due to promotion by the author rather than acceptance.)
But you could venture forth into that realm yourself. However, if you haven't ever done so or haven't done so recently, you might want to learn a little about compiler theory first. It helps.
|
|
|
|
|
Very eloquently said, Sir !
“I'm an artist: it's self evident that word implies looking for something all the time without ever finding it in full. It is the opposite of saying : ‘I know all about it. I've already found it.’
As far as I'm concerned, the word means: ‘I am looking. I am hunting for it. I am deeply involved.’” Vincent Van Gogh
|
|
|
|
|
It's time to scratch all other languages and just leave C++ alone.
Honestly, I used to write in many diff languages - about 18 of them. And you know what? I got tired. Every few months there is new, "latest and greatest" mumbo-jumbo that employers jump onto - hey, look, new buzzword. And poor programmers have to "learn", i.e. stuff into their heads that "new" APIs, new language things - just to have them to disappear in another few months for another mumbo-jumbo.
Enough for me. I don't want to waste my life permanently studing things that will gone few months down the road. And, even if they stay - sorry, no.
I chose C++, get great at it, and keep it that way.
|
|
|
|
|
I agree wholeheartedly with your sentiment about perversely curt languages.
1) Your 'FORTRAN' = example is highly flawed.
It would read: IF (X.EQ.Y) ...
No assignment confusion at all.
2) VB.NET is the answer to most of your woes.
Not C#, as it suffers far too much from the legacy of the dreadful C & C++ abortions.
|
|
|
|
|
Sounds like you want something like VB for the dynamic if you want and begin/end instead of curlies. Or perhaps Ada - though it's a lot similar to Pascal - only much more pedantic.
The trouble with the is/as/whatever "words" instead of operators - they can be very ambiguous. Especially when used as an equality comparer.
About the == for equality and = for assignment ... I'm with you. I think that might have been the worst choice in C bar none. In this case I prefer the Pascal-like := assignment and the = for equality, only slightly better. But there are languages which figure out that = is used inside a condition and thus uses its equality override, while in other cases it's an assignment. So obviously it must be possible - just that C (and its progeny) has effectively removed that possibility from their syntax.
Personally though, I don't mind characters too much. As long as they're as consistent as possible I'm fine with having a decent editor which matches them for me (indents / auto-close / etc.). It's when the "vocabulary" of these punctuation marks becomes huge with various "grammatical" rules where it becomes a pain in the @$$. Actually I hated having to type out the begin/end every single time when working in Pascal/Delphi, at least with VB some of it's automaticaly done from the IDE. But I still prefer the absolute consistency of Lisp over all other languages - everything is simply a function call, and you type it in that way too (no need to learn all sorts of different combinations for different aspects).
|
|
|
|
|
EBay has asked users to change their passwords following a cyberattack that compromised one of its databases.
That has got to hurt the ol' pride glands.
|
|
|
|
|
So depressing. Every week there's a new hack or leak from a major website. Ready for this to end!
|
|
|
|
|
Why should I use anything other than ASP.Net? "Less typing" is NOT an acceptable answer. What tangible benefits are realized by going with an alternative view engine? Since they all have to essentially provide the same functionality, I don't see the value of picking one over another.
I know - Razor is used a lot. But why? What makes it better?
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
John Simmons / outlaw programmer wrote: But why? What makes it better?
Keep in mind I'm more of a Unix guy over the web, and I've only done like one Razor project a while back...
Less typing means less room for error and cleaner code that's much easier to maintain. New constructs that make life easier, like a lambda, that has minimal penalty on performance are awesome. But, performance is king, that's why I'll never bother with something like Ruby, over the web at least. No amount of syntactic sugar can make up for slow.
Jeremy Falcon
|
|
|
|
|
MVC View Engine is:
1. Light weight
2. Separation Of concern using Model.
3. UI Injection Or View Injection
Life is all about share and care...
public class Life : ICareable,IShareable
{
// implements yours...
}
modified 22-May-14 0:19am.
|
|
|
|
|
And how that connected to the question?
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
|
|
|
|
|
Quote: Why should I use anything other than ASP.Net? "Less typing" is NOT an acceptable answer
That's why...
Life is all about share and care...
public class Life : ICareable,IShareable
{
// implements yours...
}
|
|
|
|
|
Again, your answer doesn't make any sense.
MVC is not the "view engine". The default view engines that come with Visual Studio, used by MVC, are "ASPX" and "Razor", not "MVC View".
|
|
|
|
|
Actually I missed the question I have just put features of View Engine... 
Life is all about share and care...
public class Life : ICareable,IShareable
{
// implements yours...
}
|
|
|
|
|
You missed the question. It's about why Razor over other view engines.
|
|
|
|
|
Oooo 
Life is all about share and care...
public class Life : ICareable,IShareable
{
// implements yours...
}
|
|
|
|
|
Great answer.
Suvabrata Roy wrote: Light weight
2. Separation Of concern using Model.
3. UI Injection O View Injection
You have to understand the PageController pattern to understand how you are limited by ASP.Net and why you would move to Razor / MVC. Once you understand the problems (so nicely summarized above) then you'll know.
Basically, PageController (ASP.Net) says, oh, you sent me this URL I am going to send you some HTML.
Whereas, in Razor / MVC the server sasy, Oh, you sent me this URL, I am going to do whatever the custom controller behind me says to do (calculate a value, return business objects (JSON), etc.)
ASP.Net basically returns only the view because it is a PageController pattern.
http://martinfowler.com/eaaCatalog/pageController.html[^]
|
|
|
|
|
Thaks sir... 
Life is all about share and care...
public class Life : ICareable,IShareable
{
// implements yours...
}
|
|
|
|
|
John Simmons / outlaw programmer wrote: Razor is used a lot. But why? What makes it better?
IMO, nothing.
Razor is ultimately a response by Microsoft et al. "look, we can do MVC too" and open source it, etc.
After having written and worked on several Ruby on Rails apps that employ MVC and all this embedded scripting (erb, slim, whatever) I can definitively say that, while it's slick, it's slick in a sort of slimy, geek-virgin way. Nothing becomes more unreadable faster than HTML embedded with [language of your choice] + JavaScript + jQuery + [whatever] + CSS.
On the other hand, I probably have my head up my arse in not accepting the conventions, the "idiomatic way of doing things"
, which I think is actually "the idiotic way of doing things."
On the gripping hand, I'm taking a completely radical, alternate reality approach. This is what my "view" files look like nowadays:
<%= @style %>
<%= @html %>
<%= @javascript %>
Everything is server-side generated, hopefully as I build up the toolset, from a re-usable library of standard behaviors.
Oh, and the abstraction of MVC is awesome, the reality sort of sucks, because it's actually more typing, not less, and it's amazing how many corners a cube can have in which you can paint yourself into, and then make really ugly workarounds because pure MVC leaves some horrendous skid marks when the rubber hits the road.
I'll stop now.
Marc
|
|
|
|
|
Marc Clifton wrote: After having written and worked on several Ruby on Rails apps that employ MVC and all this embedded scripting (erb, slim, whatever) I can definitively say that, while it's slick, it's slick in a sort of slimy, geek-virgin way. Nothing becomes more unreadable faster than HTML embedded with [language of your choice] + JavaScript + jQuery + [whatever] + CSS.
Even though I'm now gravitating towards Fux, proper MVC should minimize this in the view layer. It's the old-school, dump it all in one file, way of thinking that becomes a serious mess.*
* Not that I'm a fan of RoR.
Jeremy Falcon
|
|
|
|
|
I'm somewhat the completely opposite. Server side should provide data only. The data display and handling should be done on the client.
there is no problem to build a re-usable library of standard behaviors with javascript.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
