I suspect he's spent too long using JavaScript and forgotten that endline markers are obligatory in English. Newline characters alone don't cut the mustard.
you can start with a simple language (hello? BASIC anyone?
Are you insane? Start with a program that teaches you to do everything wrong? BASIC is maybe useful if your career path is moving on to 6502 assembly for embedded systems (GOTO approximates JMP, GOSUB approximates JSR), but BASIC thinking doesn't map well onto programming constructs in modern languages, or even modern processor instruction sets.
The thing is that it's not actually "simplifying" programming as much as it's dumbing it down. The real way to simplify coding is by somebody taking the time and effort to write a decent declarative language. Trying to write a simple imperative language is an invitation to inefficiency, because you end up getting people who don't understand algorithms trying to write algorithms. Or to put it another way, your optimisation is done by someone with no idea about optimisation. Yesyesyes, most compilers these days are optimising compilers. The problem with that is that most simplified languages are interpreted, so most simplified languages are never optimised at all.
Of course, this isn't just about the language itself, but what the programmer is interested in: it is essentially a contradiction for someone to write performance-critical code in Ruby, but performance is one of the major reasons one would suffer C/C++.
Which I think was one of the main points earlier up the thread -- that high-performance languages suffer more performance bugs than low-performance languages.
The work I'm doing at the moment doesn't need precise optimisation, and as long as I avoid O(n!) and O(2^n), the job will complete, and I'm happy enough. That's why I chose Python. Easy access to the things I need, and fairly straightforward to convert to a proper language once the code logic is proven.
I think I misread your point, and I think we actually agree.
Yes/no/maybe
The syntax is a bit of a frig to make it appear on one physical line, but if you can't mentally (or on a bit of scrap paper - I believe it's still allowed) convert it how it'd be written on a school blackboard) then I doubt you'd understand it whatever format it's in.
Some people do over-emphasise the maths (and in the US people seem to have a calculus fetish). I may have mistaken you for one of them. A maths-over-emphasiser, not an American.
There's two things in there -- overemphasising maths, and wrong kind of maths. Calculus isn't applicable to a lot of programming problems, so you're right that an emphasis on calculus isn't particularly helpful to the general programmer. Algebra similarly isn't much use, as in programming we generally have lots of fixed knowns, and a predefined unknown.
Graph theory, on the other hand, is an extremely useful way of conceptualising state-space and data, as graph theory leads to trees and to finite state automata. Even if you don't draw out the automata for a program you're writing, if you've properly studied FSAs, you will have learned how to think on that level of abstraction.
Set theory may not seem directly applicable, as it's not something directly compatible with the hardware layer, but there are plenty of problems that are best modelled as sets, and if you can't reason about sets, your code will end up very hacky.
You won't get very far in computer graphics without Cartesian coordinates, column vectors and matrix arithmetic. OK, so only a small part of grads are going to be dealing with graphics on that low a level. But that brings us to the crux of the debate:
Are computer programmers generalists or specialists? The current notion of this is somewhat confused. We are generalists because we are expected to be able to adapt to any type of problem; we are specialists because our skills are still relatively rare. But being generalists means not knowing what we're going to work on. If a university doesn't teach matrix manipulations, its students won't work in 3D graphics or physics modelling. If it doesn't teach statistics, its students won't work on statistical applications. The more conceptual tools we omit from our courses, the less the student can do.
The way I see it, my university did things right: we were taught general programming concepts and modes of thought. We were given the tools to think our way through problems in any area. It was a true "Computer Science" degree. On the other hand, the industry was complaining that CS grads weren't adequately trained that they could "hit the ground running" and be a productive programmer from day one, and there were more and more "Computer Programming" degrees springing up. I found myself going into my first job with a groups of peers who knew the main APIs of the most important technologies of the day and could sit at a keyboard constantly typing, but who couldn't reason through problems without the spec. Heck, on my first project, our database architect said a ridiculous thing: "you can't do that with computers". Erm... what? If he'd said that it was too big a processor load or had too high a memory requirement, that might be OK, but "can't do that with computers"...?!? Not only was it something that could be done with computers, but when I checked the documentation, it was a basic feature of the database software.
We cannot predict which conceptual tools (=mathematics) a programmer will need as long as the programmer is considered a generalist. If you want a maths-light course on computing, therefore, you have to know which field the student is going to work in. This brings us back to a notion that the teaching staff at my university discussed while I was studying there: that "programming" (as opposed to CS) should be incorporated into every degree course, adapted to the needs of the field. This was already happening with Physics and Math
They have some level of resistance to the local diseases. They don't have resistance to diseases that they have never encountered. Instead of assuring me, go and read any book on the history of contact. History is littered with the bodies of indigenous people killed by colonists' (and colonists' rats') diseases.
Yes, but my point is that someone was seriously arguing against my use of superscript exponents and the "over" line on the grounds that that was maths, and not all programmers are mathematicians. That's a million miles from prime factors and the like.
Unfortunately, contact more often than not reduces their life expectancy, as everything from syphilis right down to the common cold ravages the population. In some cases, entire tribes have been wiped out, in other cases, the tribe dropped below a viable size and had to either request a "merger" with another tribe or take the government boat downriver to a life in urban slums.
If those aliens were host to multivarious viral and bacterial infections to which humanity would have no resistance, I'd prefer they stopped for a rest at a LaGrange point and communicated only by radio-waves.
Christians sending missionaries to these villages to show them the ways of Christ.
Actually, missionaries are highly unlikely to get a permit to enter regions of the Amazon populated by isolated tribes. They even used this to deny Daniel Everett the opportunity to return to study the Piraha language. (Everett originally visited the Piraha as a missionary, but was "converted" to atheism by his experiences there. His study of the language contradicted various mainstream theories of linguistics, and rather than saying "you're wrong, but feel free to look for evidence -- you won't find any," various authority figures accused him of being a charlatan and obstructed his research. He's been successfully blocked long enough that Portuguese influence has altered the Piraha language to the point where the language features he was studying could easily have been lost, and as well as stopping him proving himself right, it's now impossible to prove him wrong. Bloody academic egos.)
First up, can I suggest adding the word "visualisation" to your standard blurb? A lot of our differences arose from the word "presentation", and my interpretation of that as low complexity. Your stargazing example was very impressive, but I was led to expect something on a very different scale from your wording and the focus on slides in your introduction videos. The graphical rendering of a huge astrological database is definitely what I would consider "visualisation".
the language confuses the two metaphors of series-of-commands vs collection-of-properties.
There is no confusion, there are only series of commands, although with a homoiconic language, they are also data, so you can view them as properties and make them behave like properties if you want to. The fundamental paradigm remains sequential evaluation (using parse tree rewrites in that case).
I'm talking about a visual confusion. The reason I keep using the word "opaque" is that when I look at the code, the intended (semantic) behaviour is obscured. You've suggested several times that having effectively only one syntactic structure in the language makes it more consistent, but my object with regards to consistency is precisely the contrary: that the syntactic rule is inconsistent because there is no clear mapping of syntax->semantics.
Ah... what I hadn't noticed was the lack of assignment operator in the language.
There is an assignment operator in the language. The theme getter/setter is define as follows:
theme -> "default"
theme T -> theme:= T
So ":=" is the assignment operator, but in all your examples you've sugared it over, and basically obscured the logic of your code...?
I may not have made the abstraction exactly like you wanted, but I've made abstraction more practical than in most languages. The theme "variable" could be a function, I would not know. And the theme T "setter" could do some validation or anything else, same thing, you would not know.
I don't think it's more practical, because it massively less readable.
If I use object.setColor("green"), it's easy to read the intended meaning.
I would prefer the abstraction object.color = "green" because getter/setter is usually implemented by convention rather than rule (leaving things open to programmer error).
But your solution offers less clarity than either. And now you're going to say that's OK, because it's a dynamic language and therefore you can write your own rules, but that doesn't solve the problem, because then the person trying to work out the original coder's meaning also has to work out the whole language before he can think about the code.
But without an operator, how is it obvious the difference between an assignment, a function passed as argument, a function call and a looked-up value?
The real abstraction is precisely that it is not obvious at the call site. If you have something like do_something theme, it's do_something that decides for example if it evaluates theme or not. If not, it gets the unevaluated name, and it can decide to do something with it, like using it as a prefix for a "function call".
You're talking about the computer. A programming language has to serve the programmer. They say Lisp is "clear" because it reveals the tree structure that the computer will parse. I find it unclear because we humans haven't lived in trees for many thousands of years. I need to see the behavioural logic, not the execution logic.
...but then again, I didn't think we were talking about processor-bound, high performance simulations, but "presentations" and "3D animations".
However, Lisp has never been all that different from well-known procedural languages except for garbage collection, closures, and the use of lists as syntax—none of which are necessary or sufficient for functional programming. These features (the first two, anyway) make it easier to write functional programs in Lisp compared to, say, C, but they don't automatically make all Lisp programs functional.
Almost. Lisp is multiparadigm. As part of that, it is a functional language, but that doesn't automatically make all Lisp programs functional. Lisp is functional because the syntax is built on expressions rather than statements (except perhaps the top-level "defines"). Code can be executed sequentially through begin...end blocks, but that's still a hack layered on top of functional syntax -- you are calling functions, then throwing away the return value (statements conceptually have no return value, although languages such as C assign success/failure flags to them). Everything is a function (even if not pure functions) and functions are first-class citizens. That's the core of FP.
(Although I personally feel impure FP is a waste of time, as it's missing the correctness and determinism of pure FP, thus not really making the code sufficiently bug-safe....)
Typical "throw more money at the problem" bullshit here. You're probably one of these "hackers" who'll just start a tantrum when they can't run [insert shitty scripting language here] on an oversized microcontroller just to display the time on a fucking LED array. I bet you even own a Mac.
We have lots of cycles spare. The problem with [insert shitty scripting language here] isn't "scripting", but "language". Most scripting languages would be just as effective compiled (getting rid of "exec" would make Python far safer, certainly) and far more efficient. There are various tools that do either full compilation or just-in-time, and they all achieve some really surprising speeds (heck, even the SpeedBasic compiler for the C64 was adequate for game programming), it's just unfortunate that these are all separate and peripheral projects. There is no theoretical reason why someone shouldn't be writing code in any language they feel like and compiling to any platform.
C/C++ certainly let you shoot yourself in the foot regarding correctness, but they generally don't make it easy to shoot yourself in the foot regarding performance. (C++ templates, exceptions, and RTTI being exceptions.)
I beg to differ. A trivial example:
int fibonacci (int n) {
if (n==1 || n==2) {
return 1;
} else {
return fibonacci(n-1) + fibonacci(n-2);
}}
Ignore the incorrectness here (the infinite recursion when passed a negative number, and instead focus on the O(2^n) execution time. It's very, very easy to shoot yourself in the foot. (That's a first-year university example -- second year at the latest.)
And of course, there is a general tendency that languages that allow optimisation end up requiring optimisation. And while automated optimisation may still not be able to outperform the most skilled human coders, most of us aren't the most skilled, and we shoot ourselves in the feet all the time....
The FizzBuzz test puts me in mind of something that was said to me on a forum recently: "not all computer programmers are mathematicians, nor should they be". This was in reference to me suggesting that code would be far more readable if we gave up our plaintext fetish and allowed our code editors to render the likes of (a+b)^2/(a-b)^2 using superscripts for exponents and showing the numerator over the divisor, as per maths.
If people think that sort of thing is too mathematical for computer programmers, I hate to think how such programmers would ever conceive of using a modulo operator to solve a problem!
But once we lower the bar that far... what the hell are they expecting people to code? I know these courses try to be as "generalist" as possible, but computers are number machines, and most useful tasks with computers involve numbers at some level...
Another point arising from the "introduction" video... the use of implicit lists for function arguments seems very, very weird. Yes, it's a "powerful feature", not a bug, I get that, but this is another example of how the language becomes opaque to reading and reasoning. Your recursive call looks for all the world like single recursion over two arguments, not list recursion.
Sorry -- I'm tired and angry about various things, and taking it out on strangers on the internet isn't really the right way to deal with it.
No, that's trying to help you become an early contributor. I would not have spent the time locating the exact line to patch otherwise. Remember, open source is about you and others being able to influence Tao3D. But since you obviously don't want to do it this time, I patched it myself. Your name in lights, tadaaa.
I have my own coding project on the go at the moment, so I'm not looking to contribute to anything else at the moment.
Well, text layout is still done in a 2D text box. So align specifies the horizontal alignment and justification within a line (the frequent case), and align_vertically the alignment and justification of the lines and paragraphs vertically.
You'll probably hate me for saying this, but why not just write text elements in an established format... like HTML?
I also realise that this flies in the face of my own moaning about internal consistency, but I see it as valid in this case mainly because of separation of concerns. I believe that the typical usage of presentations will see a lot of minor adjustment of the most PowerPoint-like elements, and very little adjustment of the 3D environment and animations. For one thing, reusing existing collateral would be more of a cut-and-paste affair, and for another, the DOM, while not perfect, is fairly well understood by a lot of admin staff who have no understanding of code.
[Added later:] Actually, after writing this bit (so thinking about the DOM), a thought came to me that's discussed further on: the language confuses the two metaphors of series-of-commands vs collection-of-properties. It's not really about pre-existing formats vs new ones.
It's an interesting point. Tao3D actually went the other way. A setter and a getter for a property typically have the same name. So to adjust the stereoscopic effect, you can say something like eye_distance 20, and that adjusts the property you get with eye_distance. To get the current theme of a slide, you use theme, and to set it theme "Master". I personally see the 'set' and 'get' in that case as noise.
Ah... what I hadn't noticed was the lack of assignment operator in the language. I see exactly what you mean about getters and setters -- my view was always that if public object properties are dangerous (and I believe they are) then the best approach would be for a code to forbid public properties, but for getters and setters to simulate properties. If that's what you've done, in theory you have completed the abstraction of objects -- if the caller doesn't need to know how an object works, it shouldn't need to know that it's not changing the properties directly.
But without an operator, how is it obvious the difference between an assignment, a function passed as argument, a function call and a looked-up value?
But I will admit it's a matter of personal taste. I hope you will understand that Tao3D reflects my tastes and not yours.
As a developer, you should be avoiding personal taste.
At the limit, we began implementing (but never finished) a system of properties named x, y, width, top and so on for coordinates. You could then use any of the following three, to your liking:
rectangle 10, 20, 30, 40
rectangle { x 10; y 20; width 30; height 40; }
rectangle { left -5; y 20; width 30; bottom 0; }
x 10; y 20; width 30; height 40; rectangle
Much like for color, the last one would also set the properties in a persistent way for following shapes to use, much like color or texture today. This means you would then be able to say something like
Richard Feynman was on the team that did the enquiry into the explosion. None of the NASA engineers would talk to him. He was visiting one of the guys he was friendly with at the weekend, and this guy was working on his car. He told Feynman that it had problems starting on cold days, and that he suspected that one of the rubber gaskets wasn't forming a proper seal. Feynman nodded quietly. At the hearings, Feynman pulled out a glass of ice water and an O-ring. Everyone in NASA knew what had gone wrong.
I lost all respect for NASA when I heard that. All their talk about "pioneers" and "calculated risks", and they couldn't even hold up their hands to a simple mistake, They killed those guys, and then they closed ranks.
Thought for the day: whenever designing something for other people to use, you should take all feedback from your potential users and prove to yourself why the feedback is correct before attempting to show the giver why it's wrong.
Why? Firstly, because nobody will give you any feedback at all if your default response is to prove to everyone that their feedback is so valueless to you (and if you don't want feedback, then this whole thread is just self-promotion, which isn't popular here).
Secondly, because we all make mistakes, so there are bound to be things in our work that are suboptimal. Admitting to yourself that there is a mistake doesn't necessarily mean having to change it -- if you honestly assess the impact of the mistake and say it's something your happy to live with, great. But it has to be a conscious decision, not denial of the problem.
Thirdly, both sides can be right, and often are. If our disagreement comes from different assumptions and use cases, you might find that if you open the dialogue (rather than shouting "FUD"), you might hear of a problem you hadn't thought of. You need to see it from not only the angle you choose to follow, but also the angle you have already rejected.
Now...
I don't like subroutine names that include something that looks like a parameter, so things like rotatex and rotatey set me on edge a bit.
If you prefer, you can use the plain rotate. But rotating along X, Y or Z is frequent enough to deserve a shortcut. Not different from CSS transform, by the way.
It gets worse when this is inconsistent, and you see a subroutine called vertical_align for vertical alignment, where the seeming parameter (vertical) is now before the generic (align), and separated by an underscore instead of run together. Not only is this an internal inconsistency, but it's inconsistent with English, as "align" is a verb, and we would put in an adverb "vertically" after the verb normally. And then it gets worse again, as the command for horizontal alignment is... "align".
You are right, align_vertically would be more sensible. Exercise for you: fix it;-)
Exercise for you: go **** yourself. That's just patronising. I'm giving you feedback, and the implication of your statement -- regardless of the smiley -- is that my feedback is valueless if I'm not willing to code it up myself. I'll say it again: if you want feedback, don't tell people you don't care about their feedback.
As for align, that's the common case, so I'd rather keep it that way.
[Citation needed] If we were just talking about text flow in a 2D page, I would agree with you, but there's so much geometry in here, I personally don't see any default.
The grammatical inconsistency continues with other commands/subroutines taking on names with no verb component at all (eg the command color, with no verb or assignment operator.
That derives from OpenGL, which has glRotate and glTranslate, but glColor and not glColorize. BUT it's not inconsistent. It's actually fairly smart. The color is an attribute, and glColor just sets it. So the name is the name of the attribute you set. glRotate and glTranslate modify an attribute (the current model/view matrix), so they are verbs.
I understand that, but it's wrong. I know a lot of people laugh at the idea of using setColor and getColor as per so many OO style guides, but really, you either need to use assignments or use verb-based names, or the syntax is broken from a human cognitive perspective. It is very difficult to reason about a grammar
Slashdot Mirror
I suspect he's spent too long using JavaScript and forgotten that endline markers are obligatory in English. Newline characters alone don't cut the mustard.
From TFA:
I'm not taking advice from computer game characters.
You forgot to instantiate the fillings.
Your timeline has a bug and won't pass review ;)
Your reviews are clearly more thorough than my last employer's...
you can start with a simple language (hello? BASIC anyone?
Are you insane? Start with a program that teaches you to do everything wrong? BASIC is maybe useful if your career path is moving on to 6502 assembly for embedded systems (GOTO approximates JMP, GOSUB approximates JSR), but BASIC thinking doesn't map well onto programming constructs in modern languages, or even modern processor instruction sets.
The thing is that it's not actually "simplifying" programming as much as it's dumbing it down. The real way to simplify coding is by somebody taking the time and effort to write a decent declarative language. Trying to write a simple imperative language is an invitation to inefficiency, because you end up getting people who don't understand algorithms trying to write algorithms. Or to put it another way, your optimisation is done by someone with no idea about optimisation. Yesyesyes, most compilers these days are optimising compilers. The problem with that is that most simplified languages are interpreted, so most simplified languages are never optimised at all.
Of course, this isn't just about the language itself, but what the programmer is interested in: it is essentially a contradiction for someone to write performance-critical code in Ruby, but performance is one of the major reasons one would suffer C/C++.
Which I think was one of the main points earlier up the thread -- that high-performance languages suffer more performance bugs than low-performance languages.
The work I'm doing at the moment doesn't need precise optimisation, and as long as I avoid O(n!) and O(2^n), the job will complete, and I'm happy enough. That's why I chose Python. Easy access to the things I need, and fairly straightforward to convert to a proper language once the code logic is proven.
I think I misread your point, and I think we actually agree.
Yes/no/maybe
The syntax is a bit of a frig to make it appear on one physical line, but if you can't mentally (or on a bit of scrap paper - I believe it's still allowed) convert it how it'd be written on a school blackboard) then I doubt you'd understand it whatever format it's in.
Some people do over-emphasise the maths (and in the US people seem to have a calculus fetish). I may have mistaken you for one of them. A maths-over-emphasiser, not an American.
There's two things in there -- overemphasising maths, and wrong kind of maths. Calculus isn't applicable to a lot of programming problems, so you're right that an emphasis on calculus isn't particularly helpful to the general programmer. Algebra similarly isn't much use, as in programming we generally have lots of fixed knowns, and a predefined unknown.
Graph theory, on the other hand, is an extremely useful way of conceptualising state-space and data, as graph theory leads to trees and to finite state automata. Even if you don't draw out the automata for a program you're writing, if you've properly studied FSAs, you will have learned how to think on that level of abstraction.
Set theory may not seem directly applicable, as it's not something directly compatible with the hardware layer, but there are plenty of problems that are best modelled as sets, and if you can't reason about sets, your code will end up very hacky.
You won't get very far in computer graphics without Cartesian coordinates, column vectors and matrix arithmetic. OK, so only a small part of grads are going to be dealing with graphics on that low a level. But that brings us to the crux of the debate:
Are computer programmers generalists or specialists? The current notion of this is somewhat confused. We are generalists because we are expected to be able to adapt to any type of problem; we are specialists because our skills are still relatively rare. But being generalists means not knowing what we're going to work on. If a university doesn't teach matrix manipulations, its students won't work in 3D graphics or physics modelling. If it doesn't teach statistics, its students won't work on statistical applications. The more conceptual tools we omit from our courses, the less the student can do.
The way I see it, my university did things right: we were taught general programming concepts and modes of thought. We were given the tools to think our way through problems in any area. It was a true "Computer Science" degree. On the other hand, the industry was complaining that CS grads weren't adequately trained that they could "hit the ground running" and be a productive programmer from day one, and there were more and more "Computer Programming" degrees springing up. I found myself going into my first job with a groups of peers who knew the main APIs of the most important technologies of the day and could sit at a keyboard constantly typing, but who couldn't reason through problems without the spec. Heck, on my first project, our database architect said a ridiculous thing: "you can't do that with computers". Erm... what? If he'd said that it was too big a processor load or had too high a memory requirement, that might be OK, but "can't do that with computers"...?!? Not only was it something that could be done with computers, but when I checked the documentation, it was a basic feature of the database software.
We cannot predict which conceptual tools (=mathematics) a programmer will need as long as the programmer is considered a generalist. If you want a maths-light course on computing, therefore, you have to know which field the student is going to work in. This brings us back to a notion that the teaching staff at my university discussed while I was studying there: that "programming" (as opposed to CS) should be incorporated into every degree course, adapted to the needs of the field. This was already happening with Physics and Math
They have some level of resistance to the local diseases. They don't have resistance to diseases that they have never encountered. Instead of assuring me, go and read any book on the history of contact. History is littered with the bodies of indigenous people killed by colonists' (and colonists' rats') diseases.
Yes, but my point is that someone was seriously arguing against my use of superscript exponents and the "over" line on the grounds that that was maths, and not all programmers are mathematicians. That's a million miles from prime factors and the like.
Nonono. Just one click was invented by Amazon, and don't let any commies convince you otherwise.
Unfortunately, contact more often than not reduces their life expectancy, as everything from syphilis right down to the common cold ravages the population. In some cases, entire tribes have been wiped out, in other cases, the tribe dropped below a viable size and had to either request a "merger" with another tribe or take the government boat downriver to a life in urban slums.
A younger Bezos saw Gene Wilder's Wonka boss the Oompa-Loompas about, and thus was his business model born....
If those aliens were host to multivarious viral and bacterial infections to which humanity would have no resistance, I'd prefer they stopped for a rest at a LaGrange point and communicated only by radio-waves.
Christians sending missionaries to these villages to show them the ways of Christ.
Actually, missionaries are highly unlikely to get a permit to enter regions of the Amazon populated by isolated tribes. They even used this to deny Daniel Everett the opportunity to return to study the Piraha language. (Everett originally visited the Piraha as a missionary, but was "converted" to atheism by his experiences there. His study of the language contradicted various mainstream theories of linguistics, and rather than saying "you're wrong, but feel free to look for evidence -- you won't find any," various authority figures accused him of being a charlatan and obstructed his research. He's been successfully blocked long enough that Portuguese influence has altered the Piraha language to the point where the language features he was studying could easily have been lost, and as well as stopping him proving himself right, it's now impossible to prove him wrong. Bloody academic egos.)
First up, can I suggest adding the word "visualisation" to your standard blurb? A lot of our differences arose from the word "presentation", and my interpretation of that as low complexity. Your stargazing example was very impressive, but I was led to expect something on a very different scale from your wording and the focus on slides in your introduction videos. The graphical rendering of a huge astrological database is definitely what I would consider "visualisation".
the language confuses the two metaphors of series-of-commands vs collection-of-properties.
There is no confusion, there are only series of commands, although with a homoiconic language, they are also data, so you can view them as properties and make them behave like properties if you want to. The fundamental paradigm remains sequential evaluation (using parse tree rewrites in that case).
I'm talking about a visual confusion. The reason I keep using the word "opaque" is that when I look at the code, the intended (semantic) behaviour is obscured. You've suggested several times that having effectively only one syntactic structure in the language makes it more consistent, but my object with regards to consistency is precisely the contrary: that the syntactic rule is inconsistent because there is no clear mapping of syntax->semantics.
Ah... what I hadn't noticed was the lack of assignment operator in the language.
There is an assignment operator in the language. The theme getter/setter is define as follows:
theme -> "default" theme T -> theme := T
So ":=" is the assignment operator, but in all your examples you've sugared it over, and basically obscured the logic of your code...?
I may not have made the abstraction exactly like you wanted, but I've made abstraction more practical than in most languages. The theme "variable" could be a function, I would not know. And the theme T "setter" could do some validation or anything else, same thing, you would not know.
I don't think it's more practical, because it massively less readable.
If I use object.setColor("green"), it's easy to read the intended meaning.
I would prefer the abstraction object.color = "green" because getter/setter is usually implemented by convention rather than rule (leaving things open to programmer error).
But your solution offers less clarity than either. And now you're going to say that's OK, because it's a dynamic language and therefore you can write your own rules, but that doesn't solve the problem, because then the person trying to work out the original coder's meaning also has to work out the whole language before he can think about the code.
But without an operator, how is it obvious the difference between an assignment, a function passed as argument, a function call and a looked-up value?
The real abstraction is precisely that it is not obvious at the call site. If you have something like do_something theme, it's do_something that decides for example if it evaluates theme or not. If not, it gets the unevaluated name, and it can decide to do something with it, like using it as a prefix for a "function call".
You're talking about the computer. A programming language has to serve the programmer. They say Lisp is "clear" because it reveals the tree structure that the computer will parse. I find it unclear because we humans haven't lived in trees for many thousands of years. I need to see the behavioural logic, not the execution logic.
...but then again, I didn't think we were talking about processor-bound, high performance simulations, but "presentations" and "3D animations".
As a developer, you should be avo
However, Lisp has never been all that different from well-known procedural languages except for garbage collection, closures, and the use of lists as syntax—none of which are necessary or sufficient for functional programming. These features (the first two, anyway) make it easier to write functional programs in Lisp compared to, say, C, but they don't automatically make all Lisp programs functional.
Almost. Lisp is multiparadigm. As part of that, it is a functional language, but that doesn't automatically make all Lisp programs functional. Lisp is functional because the syntax is built on expressions rather than statements (except perhaps the top-level "defines"). Code can be executed sequentially through begin...end blocks, but that's still a hack layered on top of functional syntax -- you are calling functions, then throwing away the return value (statements conceptually have no return value, although languages such as C assign success/failure flags to them). Everything is a function (even if not pure functions) and functions are first-class citizens. That's the core of FP.
(Although I personally feel impure FP is a waste of time, as it's missing the correctness and determinism of pure FP, thus not really making the code sufficiently bug-safe....)
Typical "throw more money at the problem" bullshit here. You're probably one of these "hackers" who'll just start a tantrum when they can't run [insert shitty scripting language here] on an oversized microcontroller just to display the time on a fucking LED array. I bet you even own a Mac.
We have lots of cycles spare. The problem with [insert shitty scripting language here] isn't "scripting", but "language". Most scripting languages would be just as effective compiled (getting rid of "exec" would make Python far safer, certainly) and far more efficient. There are various tools that do either full compilation or just-in-time, and they all achieve some really surprising speeds (heck, even the SpeedBasic compiler for the C64 was adequate for game programming), it's just unfortunate that these are all separate and peripheral projects. There is no theoretical reason why someone shouldn't be writing code in any language they feel like and compiling to any platform.
C/C++ certainly let you shoot yourself in the foot regarding correctness, but they generally don't make it easy to shoot yourself in the foot regarding performance. (C++ templates, exceptions, and RTTI being exceptions.)
I beg to differ. A trivial example:
int fibonacci (int n) {
if (n==1 || n==2) {
return 1;
} else {
return fibonacci(n-1) + fibonacci(n-2);
}}
Ignore the incorrectness here (the infinite recursion when passed a negative number, and instead focus on the O(2^n) execution time. It's very, very easy to shoot yourself in the foot. (That's a first-year university example -- second year at the latest.)
And of course, there is a general tendency that languages that allow optimisation end up requiring optimisation. And while automated optimisation may still not be able to outperform the most skilled human coders, most of us aren't the most skilled, and we shoot ourselves in the feet all the time....
The FizzBuzz test puts me in mind of something that was said to me on a forum recently: "not all computer programmers are mathematicians, nor should they be". This was in reference to me suggesting that code would be far more readable if we gave up our plaintext fetish and allowed our code editors to render the likes of (a+b)^2/(a-b)^2 using superscripts for exponents and showing the numerator over the divisor, as per maths.
If people think that sort of thing is too mathematical for computer programmers, I hate to think how such programmers would ever conceive of using a modulo operator to solve a problem!
But once we lower the bar that far... what the hell are they expecting people to code? I know these courses try to be as "generalist" as possible, but computers are number machines, and most useful tasks with computers involve numbers at some level...
Another point arising from the "introduction" video... the use of implicit lists for function arguments seems very, very weird. Yes, it's a "powerful feature", not a bug, I get that, but this is another example of how the language becomes opaque to reading and reasoning. Your recursive call looks for all the world like single recursion over two arguments, not list recursion.
No, that's trying to help you become an early contributor. I would not have spent the time locating the exact line to patch otherwise. Remember, open source is about you and others being able to influence Tao3D. But since you obviously don't want to do it this time, I patched it myself. Your name in lights, tadaaa.
I have my own coding project on the go at the moment, so I'm not looking to contribute to anything else at the moment.
Well, text layout is still done in a 2D text box. So align specifies the horizontal alignment and justification within a line (the frequent case), and align_vertically the alignment and justification of the lines and paragraphs vertically.
You'll probably hate me for saying this, but why not just write text elements in an established format... like HTML?
I also realise that this flies in the face of my own moaning about internal consistency, but I see it as valid in this case mainly because of separation of concerns. I believe that the typical usage of presentations will see a lot of minor adjustment of the most PowerPoint-like elements, and very little adjustment of the 3D environment and animations. For one thing, reusing existing collateral would be more of a cut-and-paste affair, and for another, the DOM, while not perfect, is fairly well understood by a lot of admin staff who have no understanding of code.
[Added later:] Actually, after writing this bit (so thinking about the DOM), a thought came to me that's discussed further on: the language confuses the two metaphors of series-of-commands vs collection-of-properties. It's not really about pre-existing formats vs new ones.
It's an interesting point. Tao3D actually went the other way. A setter and a getter for a property typically have the same name. So to adjust the stereoscopic effect, you can say something like eye_distance 20, and that adjusts the property you get with eye_distance. To get the current theme of a slide, you use theme, and to set it theme "Master". I personally see the 'set' and 'get' in that case as noise.
Ah... what I hadn't noticed was the lack of assignment operator in the language. I see exactly what you mean about getters and setters -- my view was always that if public object properties are dangerous (and I believe they are) then the best approach would be for a code to forbid public properties, but for getters and setters to simulate properties. If that's what you've done, in theory you have completed the abstraction of objects -- if the caller doesn't need to know how an object works, it shouldn't need to know that it's not changing the properties directly.
But without an operator, how is it obvious the difference between an assignment, a function passed as argument, a function call and a looked-up value?
But I will admit it's a matter of personal taste. I hope you will understand that Tao3D reflects my tastes and not yours.
As a developer, you should be avoiding personal taste.
At the limit, we began implementing (but never finished) a system of properties named x, y, width, top and so on for coordinates. You could then use any of the following three, to your liking: rectangle 10, 20, 30, 40 rectangle { x 10; y 20; width 30; height 40; } rectangle { left -5; y 20; width 30; bottom 0; } x 10; y 20; width 30; height 40; rectangle
Much like for color, the last one would also set the properties in a persistent way for following shapes to use, much like color or texture today. This means you would then be able to say something like
If the management don't accept the advice of their experts, that's criminally negligent in my book, as they're ignoring the best possible data.
Richard Feynman was on the team that did the enquiry into the explosion. None of the NASA engineers would talk to him. He was visiting one of the guys he was friendly with at the weekend, and this guy was working on his car. He told Feynman that it had problems starting on cold days, and that he suspected that one of the rubber gaskets wasn't forming a proper seal. Feynman nodded quietly. At the hearings, Feynman pulled out a glass of ice water and an O-ring. Everyone in NASA knew what had gone wrong.
I lost all respect for NASA when I heard that. All their talk about "pioneers" and "calculated risks", and they couldn't even hold up their hands to a simple mistake, They killed those guys, and then they closed ranks.
Thought for the day: whenever designing something for other people to use, you should take all feedback from your potential users and prove to yourself why the feedback is correct before attempting to show the giver why it's wrong.
Why? Firstly, because nobody will give you any feedback at all if your default response is to prove to everyone that their feedback is so valueless to you (and if you don't want feedback, then this whole thread is just self-promotion, which isn't popular here).
Secondly, because we all make mistakes, so there are bound to be things in our work that are suboptimal. Admitting to yourself that there is a mistake doesn't necessarily mean having to change it -- if you honestly assess the impact of the mistake and say it's something your happy to live with, great. But it has to be a conscious decision, not denial of the problem.
Thirdly, both sides can be right, and often are. If our disagreement comes from different assumptions and use cases, you might find that if you open the dialogue (rather than shouting "FUD"), you might hear of a problem you hadn't thought of. You need to see it from not only the angle you choose to follow, but also the angle you have already rejected.
Now...
I don't like subroutine names that include something that looks like a parameter, so things like rotatex and rotatey set me on edge a bit.
If you prefer, you can use the plain rotate. But rotating along X, Y or Z is frequent enough to deserve a shortcut. Not different from CSS transform, by the way.
It gets worse when this is inconsistent, and you see a subroutine called vertical_align for vertical alignment, where the seeming parameter (vertical) is now before the generic (align), and separated by an underscore instead of run together. Not only is this an internal inconsistency, but it's inconsistent with English, as "align" is a verb, and we would put in an adverb "vertically" after the verb normally. And then it gets worse again, as the command for horizontal alignment is... "align".
You are right, align_vertically would be more sensible. Exercise for you: fix it ;-)
Exercise for you: go **** yourself. That's just patronising. I'm giving you feedback, and the implication of your statement -- regardless of the smiley -- is that my feedback is valueless if I'm not willing to code it up myself. I'll say it again: if you want feedback, don't tell people you don't care about their feedback.
As for align, that's the common case, so I'd rather keep it that way.
[Citation needed] If we were just talking about text flow in a 2D page, I would agree with you, but there's so much geometry in here, I personally don't see any default.
The grammatical inconsistency continues with other commands/subroutines taking on names with no verb component at all (eg the command color, with no verb or assignment operator.
That derives from OpenGL, which has glRotate and glTranslate, but glColor and not glColorize. BUT it's not inconsistent. It's actually fairly smart. The color is an attribute, and glColor just sets it. So the name is the name of the attribute you set. glRotate and glTranslate modify an attribute (the current model/view matrix), so they are verbs.
I understand that, but it's wrong. I know a lot of people laugh at the idea of using setColor and getColor as per so many OO style guides, but really, you either need to use assignments or use verb-based names, or the syntax is broken from a human cognitive perspective. It is very difficult to reason about a grammar