New Idea to construct new programming language for newbie (N+)

[BigEd781]

I haven't taken the time play around with LINQ (https://www.simple-talk.com/dotnet/.net-framework/fluent-code-in-c/) or other similar interfaces but from what I've seen on stackoverflow it looks pretty...newbie friendly syntax?

The important part about LINQ is not solely syntactic. Yes, the comprehensions are nice, but there are semantic changes as well. 1. Lazy evaluation. That enumerable is not evaluated at that line. The evaluation comes when it is first accessed. This means that a) you don't pay for what you don't use, and that string of multiple filters can be optimized into a more efficient construct (e.g., you're not necessarily performing 4 O(n) operations there).

This is important as it allows relatively efficient access to a data store, wherein your LINQ syntax is translated to the appropriate query syntax. The underlying implementation, i.e., expression trees, are also very powerful and can be used by others to create additional libraries.

So, yet another example of how learning the lower level bits is more important than focusing purely on syntax. There is a reason for these things, they're not just shiny baubles. To really "get it" you need to learn the complicated stuff anyway. In that same vein, there is also a trap here; what happens in the following code?

// assume that "db" is an object which represents a data sourcevar orders = db.Orders.Where(o => SomeCondition(o));var firstOrder = orders.First();foreach(order in orders.Skip(1)){ DoSomething(firstOrder, order);}We enumerate the enumerable twice. That means that, because of lazy evaluation, the .Where() call is evaluated twice, i.e., we hit the data store twice. That can be expensive and, if you don't know how your code works at a deeper level, you'll have made a mistake that could take you quite a while to fix. (As an aside, add a ToList() to the query and you'll evaluate it once and cache the result). No amount of dumbed down syntax is going to save you here.This may seem tangential to the topic, but it's not. My point here is that you think changing terminology makes everything simpler, but it doesn't. You still have to learn the harder stuff and you have done nothing but fracture the programming community. Users of your language will be utterly lost when they have to transition to a new technology where all of the terminology is different.

 

[XinChao]

There are a lot of problems here. The first I think is the big one; there is no good reason for programming languages to be readable by those not involved with programming. Why? Because being a software engineer is not trivial and, no matter how you package it, becoming proficient will take time and effort. Once you put in that time then the constructs you claim are confusing will make perfect sense. Many of these choices have good reasons behind them, let's go over them.

1. The term "variable" is not confusing. If you couldn't be bothered to learn what the term means when you took your first algebra class then you'll probably have a tough time learning to be a programmer.

2. '=' for equality has been done before, this is not new. Go play around with VB, a language almost universally reviled by developers. It tried to simplify the syntax of C like programming languages. It did bring a lot of new blood into the industry. Unfortunately, perhaps partly due to the fact that the language attempted to insulate them from the more complicated bits, many of these newcomers wrote horrible, God awful software.

3. Arrays. Yet another suggestion to call one thing something else. "A rose by any other name" and all that...
 

When I see suggestions like this I wonder if you have thought this through at all. If that line "returns all the stuffs in the array" then, well... it does nothing at all! You already have the array, which is a container for multiple objects. Returning all of them is simply returning the array itself.

Your proposed changes are completely superficial and don't actually improve anything semantically. All abstractions are leaky. Call constructs what you will, it doesn't help people solve performance issues. It doesn't help them learn to debug subtle logic errors. It doesn't help them to become competent developers.

It's also an old idea; dumb down the terms and syntax and you make it easier to learn to program. This has been shown to be false time and time again. Everyone worth their salt makes it past syntax quickly. Learning syntax accounts for perhaps 0.005% of the time you spend learning how to build software. It's the easy part.

You can simplify that part all you like (and not always for the better), but once that is done you are left with all of the hard problems, and those don't get any easier. A standardized terminology exists for a very good reason; namely, so that those in the know can easily and quickly express their ideas to one another. You may feel that changing a name is a good thing, but now you have caused a terminological rift between people using different technologies. You have lost far more than you may have gained.

You seem to be under the impression that learning a language is the same thing as being a developer/engineer. It is not. Languages are the easy part, they're just tools. Solving problems with your toolset is the tough bit, that's what separates the wannabes from the experts.

You are a beginner. You stumbled over syntax and terminology, so you are assuming that this is the stuff that makes it hard for people to become proficient. Of course, you lack the experience needed to make that determination. I assure you; this is not the hard part. Programmers don't have trouble building complex systems because their arrays are zero-indexed and called "arrays" instead of "containers".

It's semantics and, later, logic issues that make it hard. It's building large, complex systems that communicate between various pieces in order to solve really tough problems that keeps people like me employed. I can jump between at least eight different languages without breaking a sweat. They all have different syntax and semantics, but it doesn't matter; I learned them long ago. My job is to use them to do something useful. That's what's important, not what symbol they use for checking equality.

You should also take some time to consider that these languages were designed by people with much, much more experience than yourself. Don't be so quick to write off their decisions; you likely don't understand the "why" behind them yet. Without understanding and experience you cannot hope to do better.

P.S. If you want an example of a well designed language which mimics everyday speech, look into fluent programming. This was created by a man who is prolific in our field (Donald Knuth). He is a true genius. No one uses fluent programming in practice. The only language that no one complains about is a language that no one uses.

While things you said may be true with the level experience and your knowledge in programming and I can't argue with you on that since I am not up to your level however I think you miss the point and I think our philosophy are different, it could be the influence from our working enviroments. Your philosophy similar to the Ruby's developer, programming should be designed for programmers. I am 8 years+ working in the army. The mindset and philosophy there are to keep every thing simple and stupid, straigth foward and avoid confusion even when you have to set up a complex communication system, you always have to make sure that it is simple that people can understand. That means you can't just do whatever you want base on your personal preference/style which Ruby is allowing you doing right now "Ruby Philosophy There are many ways to make things done" Things in the military has to follow strict rule and must keep it simple and avoid any confusion even though sometimes it looks stupid to follow standards set. Think of Ruby Ternary for If Else statement as exmaple I dont think of the reason there is need of ternary which just make  things more complicate.

The problem you look at this idea is that you look into it via a scope of a programmer, how about think of this idea is of a  language to serve as, a bridge for kids, or non-programmers to play, to get familar with the structure and concept of programming language] instead of thinking this new idea will compete with C or C++. Think of Rpg Maker, can it really compete with Unreal Engine which use C++ to make games? Of course not, It was made as a toy, current RM can't even port to browers or smart phones but many people use RM and majority RMare  not professions in game making, most games they made more for hobbies players only a few exceed the commercial game made by Unreal Engine. What the RM done right is it provides entry for people who has gaming passions. It is so easy that a kid can make a game now day with RM.

The variable you mentioned, honest, I got B+ in Calculus when I was in college., that does not mean I will remember all the math's terminolgies  when I have not touched any math at the level of Calculus for 8 years. If you use some terminology in math to speak to me I will have to wonder. If you use object that every day use to explain what you want to tell me then I would understand right away. That is the goal of the  idea. Isn't Ruby everything object why not use object that everyone can visualize instead of something unfamiliar and can't visualize? I dont get it.

The Ruby, I have capability to learn and understand, I just really dont like it when it tends to make things more complicate than it should be the opposite, to make it more simplify. I again, I use ternary for example; I though include? was ternary but it is actually a Ruby method.  It use question mark twice, one for ternary and one for method, I wonder if Ruby has no other way to make it better?

 

[Engr. Adiktuzmiko]

.include? only uses 1 question mark by default...


unless you're doing


condition ? true : false


but if you're just doing a simple boolean check, you only use 1


if list.include?(item)


Right?


btw,

It is so easy that a kid can make a game now day with RM.

To make a game, yes... to make a good game, no... it still takes lots of effort... people who think like you are the ones causing problems for people trying to get RM games back in the good light... always saying that, kids can do it...

 

[Andar]

While things you said may be true with the level experience and your knowledge in programming and I can't argue with you on that since I am not up to your level however I think you miss the point and I think our philosophy are different, it could be the influence from our working enviroments. Your philosophy similar to the Ruby's developer, programming should be designed for programmers. I am 8 years+ working in the army. The mindset and philosophy there are to keep every thing simple and stupid, straigth foward and avoid confusion even when you have to set up a complex communication system, you always have to make sure that it is simple that people can understand.

While I can see both points and agree with the principle to keep everything easy (I've worked six years in helpdesk, and believe me the common helpdesk jokes about customers are NOT exaggerated), you're still missing the point XinChao.
The computer requires a certain level of logic abstraction in order to work, and you cannot prevent people from learning that abstraction skill if you want them to be able to program anything.


BigEd made a topic about "cargo cultist programmers" - I linked it in my first post on the previous page: http://forums.rpgmakerweb.com/index.php?/topic/5108-a-good-article-for-you-budding-scripters/


That is a perfect description what you create when you try to reduce the complexity of programming too far.


Yes, if you reduce the terminology of programming languages then some more people will be able to understand what you write - but they won't learn how to program.


BigEd's example about Arrays is the perfect example. Let's take a look at your own words:

How do we access this container?


CellContainer.get[10]


When you read it is like this, get the cell 10 in the cell container. How we access or iterator the Array. We can use this


CellContainer.get[ALL]


Above return all the stuffs in array.

You will NEVER want to return everything from an array.


The computer is a machine that can handle only one object at a time, which means it can never handle everything from a group - it needs a way to count through that group, and it needs to be told how to count through that group.


THAT is the reason why all iterations have additional counters and conditions to create the loops that process the elements in the array, however they are called and counted.


The computer is the most stupid object in the world, it has an IQ of Zero (even the worst human people are more intelligent) and there is a reason why programming has lead to sentences like "GIGO - garbage in means garbage out".


The programmer is the teacher who trains the computer (as the most stupid pupil imaginable) how to work, and he/she needs to do that in the language the computer understands.


And the computer doesn't understand the same terms as even a simple human can. So the programmer needs to learn how the computer talks, because there is no way a computer can learn how a human talks (otherwise we would have been able to create artificial intelligences by now).


And please, don't come with an example of recognition programs for the computer's ability to understand humans - there is a reason why it took a world full of programmers sixty years of constant improvements to get to today's expert systems - and even they are extremely limited as soon as you go outside of pre-selected parameters...

 

[BigEd781]

While things you said may be true with the level experience and your knowledge in programming and I can't argue with you on that since I am not up to your level however I think you miss the point and I think our philosophy are different, it could be the influence from our working enviroments. Your philosophy similar to the Ruby's developer, programming should be designed for programmers. I am 8 years+ working in the army. The mindset and philosophy there are to keep every thing simple and stupid, straigth foward and avoid confusion even when you have to set up a complex communication system, you always have to make sure that it is simple that people can understand. That means you can't just do whatever you want base on your personal preference/style which Ruby is allowing you doing right now "Ruby Philosophy There are many ways to make things done" Things in the military has to follow strict rule and must keep it simple and avoid any confusion even though sometimes it looks stupid to follow standards set. Think of Ruby Ternary for If Else statement as exmaple I dont think of the reason there is need of ternary which just make  things more complicate.

Two different needs here. The military needs processes which can be followed by essentially anyone. Think McDonald's. Software development is a skill position. What I'm saying is that the things you don't like make sense, you just have a hard time seeing it because you are inexperienced. Einstein said "Everything should be made as simple as possible, but not simpler."


You can't simplify programming into something trivial and easy by changing terminology. This stuff is the easy part, that's what you don't get yet. Your suggestions are all along the lines of calling "X" "Y" instead and you think that will make it easy to write code. It won't. Have you ever read an abstract or a whitepaper on an algorithm? It uses a lot of mathematical jargon.


At first you may think it is unnecessary and confusing, but this allows anyone versed in the "language" to understand it easily. It is a common set of terms, what things are called is almost irrelevant. You would do away with a common terminology because of a misguided notion born of inexperience.

The variable you mentioned, honest, I got B+ in Calculus when I was in college., that does not mean I will remember all the math's terminolgies  when I have not touched any math at the level of Calculus for 8 years. If you use some terminology in math to speak to me I will have to wonder. If you use object that every day use to explain what you want to tell me then I would understand right away. That is the goal of the  idea. Isn't Ruby everything object why not use object that everyone can visualize instead of something unfamiliar and can't visualize? I dont get it.

This sort of proves my point; if you forgot all that you learned in that class, you weren't learning concepts, you were memorizing how to solve equations that look a certain way. Math is typically taught in the most dumbed down manner possible. Memorize this, memorize that, monkey see, monkey do. That's not math. Math is about concepts and problem solving, just like programming.


Anyway, if you haven't done any real math in eight years then I daresay you're not their target audience. Why should mathematicians strive to express their ideas in terminology so simple that a laymen can understand it? What is the purpose? Do you really believe that, if Newton dumbed down his prose in the Principia we would have seen an increase in the number of accomplished physicists during that time period? I don't think so.


If you want to make a language with no meaningful differences between it and anything else out there for the sake of changing terminology then fine, do it. It will do more harm than good. You will have a bunch of beginners who understand your limited terminology and are ignorant of the actual world of programming. They will all have to learn the real stuff anyway, and you haven't convinced me that your proposals are actually better.


Seriously, the term "array" is not confusing. Look it up in a dictionary, it makes perfect sense. Calling an array a "container" doesn't make solving programming problems easier. I say again; you are confusing programming with learning languages because you are a beginner. That's ok, everyone starts somewhere, but don't get ahead of yourself. As someone with more experience than you I am saying that learning languages is the easiest part of programming.


You want to make programming easier? Write a threading library that hides all of the nasty bits and makes it easier to write parallelized code (these exist already). Write a set of non-blocking, thread-safe container classes and data structures. Write a hardware description language that does a perfect job of mimicking the underlying hardware on a large number of different platforms. Write the next generation of machine learning algorithms in order to improve automated detection of, well, anything really (you'd be amazed at some of the applications here; I use them to detect cancer cells in a sea of normal cells at my day job).


These are problems worth spending time on, not thinking up a new term for "variable".


EDIT: I feel I should stress once more that this idea is not novel. It has been done before. Experienced programmers don't like it. We understand our terminology perfectly well and there are good reasons for standardization. It's not so that we can feel smarter than everyone else, it's a sub-language that we all understand. If I'm talking about a problem with someone I want to focus on semantics, not explaining the newfangled terminology my super-awesome language uses.


Perhaps we could find a better name for some of these constructs. It doesn't matter; at this point these terms are standard, and changing them does far more harm than good.

 

[Tsukihime]

To make a game, yes... to make a good game, no... it still takes lots of effort... people who think like you are the ones causing problems for people trying to get RM games back in the good light... always saying that, kids can do it...

You're missing the point (or at least, what I think is his point): you don't need to be a programmer to make a game, and that's the great thing about RM.


So if people are willing to "dumb down" the game making process, why not dumb down the programming process?


You can obviously see the problems with RM because it dumbs things down too much, but just because there are problems, doesn't mean it's a bad idea.

The military needs processes which can be followed by essentially anyone. Think McDonald's. Software development is a skill position.

But he's not talking about software development. He's talking about programming languages; a way to tell the computer to do stuff.


I don't need to be a software developer to write batch/shell scripts to automate jobs.


Granted, I wouldn't call myself a software developer in the first place if that was what I did for a living, but I'd still say I have "programming skill". (though some people do say they are "programmers" despite only being able to use macros in microsoft excel)

At first you may think it is unnecessary and confusing, but this allows anyone versed in the "language" to understand it easily

That's the problem: a lot of people can't get past the first step.


If assembler was all there was to programming languages, I wouldn't want to touch programming either. Does that mean I'm just not cut out for it? Maybe.


I picked up programming in Python easily, but it took a lot longer to understand C, and even now I don't want to touch C if I don't have to.

Well if you haven't done any real math in eight years then I daresay you're not their target audience

I don't need to be a mathematician to be a programmer.


Variables can be explained in very simple terms

• I have a box. Call it A.
• I put a kitty in the box. The box called "A" holds a kitty
• I take out the kitty and put a dog in it. "A" now holds a dog

This should be sufficient enough to understand, at the very least, how a variable works, and if people still don't get it, find another example. THEN after people are comfortable with the idea, then you can talk about memory and all that complicated things.
This is what teachers go through all the time; it's their JOB to get even stupid people to understand complex concepts because parents think their kids are the brightest things in the world and if they can't understand it then it's the teacher's fault.

Why should mathematicians strive to express their ideas in terminology so simple that a laymen can understand it? What is the purpose?

So that more than a select group can understand it. I don't see the problem with making it easier to understand certain concepts.


Mathematicians don't have to express their ideas in layman's terms, but someone who understands the concepts AND has the motivation to teach it to others in layman's terms, is someone I find is more respectable than those that just stick their noses up at simple people that can't understand their refined art.


High-level programming languages are already a big improvement over low-level languages in terms of learning the stuff, but that doesn't mean it couldn't get easier.


There are a lot of people with elitest attitudes towards programming. Three second google leads me to this question, which is a legitimate question: Why do we teach assembly language programming

- One of the reasons we teach assembly to novice programmers is so that they will no longer be novice programmers, that is to help them gain insight to the low level functioning of the machine.


- the amount of stupid programmers out there having no clue what actually happens in a computer is sadly way too high. Knowing your tools is never bad


- any computer scientist or programmer should know how the chip works at a very low level

I write tools to help people get work done. I honestly care very little how the computer works, much less a computer chip. I can understand the value of understanding how the computer works and how it impacts algorithms and programs, but a chip?


Sometimes I might read about it to get a better idea how it actually works, but for the most part, I just trust that it works and does what I need to do, and if someone points out a problem because they know more about computers than me, I'll just adapt it.


Does a mechanic need to understand how his power tools work in order to be called a mechanic?


That's probably a bad example cause I don't know what mechanics actually do, or what kind of mechanics there are.


How about, does a web designer need to know how a browser works, in order to make nice websites?

 

[BigEd781]

How about, does a web designer need to know how a browser works, in order to make nice websites?

I don't have time to respond to all of that right now, but I can take a swing at this one; yes, they do, at least, they do if they ever want to do anything non-trivial.

You need to know how the rendering engine works to fix problems in your layout. You may need to know how and when resources are downloaded in order to fix a performance problem. You need to have at least a basic understanding of TCP. You need to understand the client/server model. You need to know the quirks of each browser that you support.

This is the crux of the argument; once you step off of the bunny hill you need to know how your abstractions work. It is inevitable. You will run into a problem at some point and, if you don't know what is going on inside that big black box, you'll be hopelessly lost. This is what happened to all of those awful VB programmers.

Further reading: http://www.joelonsoftware.com/articles/LeakyAbstractions.html

EDIT: ok, one more thing. I see this a lot in RM scripts when working with images.

image = get_some_image;image.width.times do |x| image.height.times do |y| pixel = image.get_pixel(x, y) # oops endendThat is naive code and will run terribly slowly. You know why? The backing array for the pixel data is just one big array of bytes. Images are stored row order. This means that, if you iterate row-wise, your pre-fetch will work splendidly. It will grab chunks of that array and fill up your L2 cache. So, iterate this way, and your access pattern will be optimal.Of course, most of us think column-major for some reason. When we iterate over the pixels in an image we think "x then y". Well, the result is the code above, which has you jumping all around in memory. Every pixel access will likely cause a cache miss. Your cache may be purged and filled again, needlessly accessing memory and loading it into your CPU's cache just to be flushed in the next iteration.

No amount of terminology changes will fix this sort of thing and these are the sort of problems real programmers deal with. So, when hear ideas like this I just think "beginner" because no programmers are actually having problems with this stuff. And I would point out that no one has actually addressed the biggest problem with this (that I have no mentioned twice). Cause a rift in terminology and you cause a rift between programmers. They lose their ability to effortlessly talk to one another about details. Jargon exists as a standardization of sorts. It doesn't really matter what words we use, only that everyone is on the same page.

 

[Galenmereth]

If you abstract things too far in any direction, you make it just as hard to learn the details later on as it was to learn the abstractions early on. And by details I don't mean machine code or byte wrangling; but eventually you will need to know why a language works like it does, because if you ever make some slightly complex software, you'll encounter its quirks sooner rather than later. It's simply not a good idea to teach people about programming using another new language that is completely different from everything else.

I actually taught a couple of intro level classes of ActionScript 2 a long time ago, to a classroom of graphic designers that had no experience programming or coding, or even writing basic HTML. What had made it hard for them to get the basics of programming wasn't that you call an array an array, or that variables are called variables; it was that every single book or online video they had watched didn't present it in a practical way for them. This was the reason I decided to do the class at all; to test out a theory of mine, which was that graphic designers think visually, and drawing is very much "practical"; what you draw is, after all, what you get, right? So what if I started out with tiny Flash problems like "move this ball from one side of the screen to another, but only with a line of code" and things like that, showed them a way to do it, and then tell them to see what happens if they switch out some things, like Y instead of X, and the numbers after the = sign. After letting people play around with that for a few minutes, I would describe what was going on – pretty detailed explanations too.

I then introduced variables instead of writing the positions directly, so you could reuse it for multiple objects, and built upon the visual examples and problems like this over a course of a few weeks. Over this time I got a lot of feedback; some were still unsure about some things, so I would cover that again in a different example the next week, but eventually everyone got these basics of the language syntax and understood why it worked.

So my five cents is, instead of creating yet a new language for people to use, why not come up with better ways of teaching newcomers how to program, and how things work? Why not take that frustration you feel as you learn to program, and figure out how to teach it in a better way to others that are like you? I got lucky stumbling on a book that hit that sweet spot of learning through experimentation, while also being technical enough to actually teach me all the important bits. But it took me two years of playing around with the original actionscript before I found that book. The more variations there are in learning material, the bigger the chance gets that more people can learn to actually do it. Another language, which would then need another series of books and lessons which deviate completely from everything else, will not.