Temple of The Roguelike Forums
Development => Programming => Topic started by: Krice on July 22, 2016, 12:03:39 PM
-
I think most if not all programming languages kind of suck. So how about creating a new programming language? How hard it could be. I guess implementing is much harder than just a design. What I would like to do is rethink everything and not try to create another oop/functional whatever mess. There has to be more clever way.
-
lol
-
I created a programming language for myself :)
I did last three 7drls using it.
I'd say design is as hard as other parts.
If you aim for statically typed language compiled into native binary, than there is llvm.
You can generate .NET CLR, or Java bytecode.
Or create own VM for dynamically typed language (what I did).
Jonathan Blow is working on new programming language, and progressing quite well.
So, it's not really hard.
-
Jonathan Blow is working on new programming language, and progressing quite well.
So, it's not really hard.
I think the problem with languages is that they are created by programmers, scientists and engineers. You know, that bunch. I'd like to see a language designed for humans, who then can write programs for computers. Languages are getting even worse, just look at the new stuff in C++.
-
When people other than programmers/scientists/engineers develop programming languages, stuff like COBOL, Java and php happens, so… no thanks!
Writing your own language is surprisingly easy. It just doesn't help that much. I wrote Poslin (https://bitbucket.org/thomas_bartscher/poslin) with a whole standard library (https://bitbucket.org/thomas_bartscher/poslin-lib) and I intend to continue working on both (because I actually really like it – is there any other language in which the user can add their own optimization passes? I only need to add the corresponding syntax making it easy enough…), but for the moment I do everything else in Common Lisp either way – when I need another way of expressing my idea of what the program should do, I write the macros which allow me to express it in a way that suits me.
My advice is this: Try to formulate what you want your language to be like. You can start fuzzy, but you will need to get concrete very fast.
You'll need to write prototypes to test your ideas – something that seems nice in your head might not work out when you actually try to program in it. Some stuff you thought would make your life easier might actually make programming incredibly hard because it has strange corner case behavior you didn't think of – avoiding these corner cases with checks doesn't really help, especially since it will make the semantics of your language even harder to understand.
-
I am pretty sure languages being created by programmers and engineers is the sole reason humans can write programs at all. Let non-engineer write an algorithm and only a trained neural network of another human will have any chance to reliably execute that.
And I doubt any programming language inconveniences can actually bury a really good and interesting idea. It is just a tool after all. Actually, in my experience, most of the better results (be that programming, DIY, photos, etc.) were produced with subpar tools and equipment, whatever was at hand at the moment of inspiration.
-
When people other than programmers/scientists/engineers develop programming languages, stuff like COBOL, Java
I think Cobol is extremely engineer based. Java is different, it was supposed to be a "better C++" which is never a good starting point to create a new language. Java and D both tried to fix C++ but it doesn't work that way.
When I've been working on a large scale roguelike one of the things that has always interested me is the relationship between code and data. There is something about handling data that feels "wrong" if you know what I mean. I don't know what it is exactly, maybe the rigid way C++ handles data in extremely low level way.
-
Making one's own language is bound to be a fun exercise. So if you have the will and time, go for it. I wouldn't expect to come up with anything objectively "better" than already existing tools, although it's of course possible to tailor something to one's own taste and needs. Put differently, I would guess that writing your own language to make a RL would add a lot of development time (even if implementing the game itself would go quicker with something homemade).
As always,
Minotauros
-
When I've been working on a large scale roguelike one of the things that has always interested me is the relationship between code and data. There is something about handling data that feels "wrong" if you know what I mean. I don't know what it is exactly, maybe the rigid way C++ handles data in extremely low level way.
That suggests a few things to me:
1. You want a language with value- instead of variable-typing.
2. You may want to look into reactive programming, which is describing programs similarly to (but more general and flexible than) spreadsheets.
3. You want automatic garbage collection.
I'd recommend Common Lisp (of course) together with cells, but cells isn't in quicklisp anymore. I don't think you'd like Haskell with reactive-banana, judging by your dislike of functional programming. I don't really know which other languages have something similar.
-
I'd recommend Common Lisp (of course)
I guess some of these days I should really try Common Lisp or another language that has ridiculous syntax. Just to see if it's actually possible to write any kind of program. At my age it's.. eh.. common to quit stuff if they look like there is some kind of learning curve or barrier to climb over.
-
I learned programming with Delphi, Haskell and Prolog in school. I tried for years to grok C/C++ and never got anywhere – of course I understood the principles, but that somehow never coalesced into anything usable.
When I picked up Common Lisp, it just clicked and everything fell into place. he syntax is the most natural I can imagine. For me other languages have ridiculous syntax. It's all a matter of perspective.
-
Let me guess, you are studying math?
-
You're wrong, but only by a technicality. But knowing math has nothing to do with understanding Lisp, especially since in math at the University Java (urgh) seems to be the language of choice.
I embrace both math and Lisp because both have a focus on cutting down rules to the bare minimum. The less rules I have to keep in my head, the better.
C and everything close to it seems like a huge pile of rules which don't lead to anything interesting. Lisps are smaller collections of rules which interact in awesome ways to allow for extremely powerful stuff.
-
I embrace both math and Lisp because both have a focus on cutting down rules to the bare minimum.
I've started to read CL manual. So it seems to be like other languages, but with shortened, more cryptic syntax. Yeah, like, that's going to help a lot.
-
What CL manual? The Hyperspec? The manual of some CL implementation?
If you think that CL is like any other programming language you are factually wrong.
-
If you think that CL is like any other programming language you are factually wrong.
Please do tell what is so different about it.
-
I'd really like t know what you were reading, that would give me some idea what you might already know.
And given by your behavior up to this point I'd wager everything I could show you would either be not impressing enough or too complex for you to understand in a timespan that you'd consider worthwhile. I mean, how much time have you spent with Common Lisp before dismissing it? Half an hour? Cannot be more than that if you haven't even found out about macros yet.
But just for you, here's a demonstration of some stuff that is possible in Lisps. If you don't understand what's going on here I'd advise searching out some actual tutorials on Lisp, like, I don't know, Practical Common Lisp (http://www.gigamonkeys.com/book/) or this sample chapter from Land of Lisp (https://www.nostarch.com/download/Lisp08.pdf) or if you want to dive into the more unusual stuff straight away because properly understanding a language is for babies, you can read On Lisp (http://www.paulgraham.com/onlisp.html), which is all about macros. I'd also recommend buying "Let Over Lambda", but I assume making such an investment isn't really useful for someone with the patience of a cat.
Let's start with something trivial.
When looking something up in a collection oftentimes you get either back the object you were looking for, or a "NIL" value. This normally looks like this in code:
(let ((targeted-monster (find-occupant square)))
(if targeted-monster
(hurt targeted-monster)
(message "There's no target at this point!")))
It's not really that much, but after a while it gets tedious to do that all the time. So I'll write a macro to do it for me:
(defmacro [a]if (test then &optional else)
`(let ((it ,test))
(if it
,then
,else)))
Now I can write code as above like this:
([a]if (find-occupant square)
(hurt it)
(message "There's no target at this point!"))
That already saves a lot of typing.
But that's trivial. Barely worth talking about.
I don't know whether you know about the difference between eager and lazy evaluation. If you don't, go read up on it.
Most Lisps are eagerly evaluated, especially since Lisps are very decidedly not functional and lazy evaluation tends to behave weirdly when side effects are involved unless special care is taken to avoid these problems.
Still, lazy evaluation can be tremendously useful in parts of a program not relying on side effects. Although Common Lisp does not support lazy evaluation out of the box, you can implement it. There are many ways to do this and I'm going to show you the easiest way of doing it, not the most useful one:
(defmacro freeze (&body body)
`(lambda ()
,@body))
(defun force (thunk)
(if (functionp thunk)
(funcall thunk)
thunk))
Those to alone aren't that useful, but more powerful macros can be written atop them to make them more useful:
(defmacro let~ ((&rest bindings)
&body body)
`(thunk
(let (,@(mapcar (lambda (binding)
`(,(first binding)
(force ,(second binding))))
bindings))
,@body)))
and so on. I've got a more involved library for the whole thing here (https://bitbucket.org/thomas_bartscher/cl-adt), which relies on this (https://bitbucket.org/thomas_bartscher/cl-lazy-object). That library also implements algebraic data types and pattern matching on those algebraic data types.
Of course that's still small fries. writing some lazy evaluation library is only a few steps above writing a "Hello, world!", even if tons more useful.
I already know you think little of entity-component systems, but I find them to be incredibly useful. There already are some implementations for them on the net, but because they all relied on a central system loop to access them, which is too restrictive for my tastes and provides features I really don't need, so I rolled my own.
Entities themselves are simple objects, and the can be created like this;
(entity)
They aren't particularly interesting in themselves. The interesting parts are the components. To define a certain type of component, I can do one of the following:
To define a component with an already existing type:
(define-component-type strength (integer 0))
To define a component as a structure type:
(define-component-struct inventory ()
(content (empty-set)
:type set)
(capacity 0
:type (integer 0)))
Components can also depend on other components being present.
And then I can write functions which will only be run on entities in which certain components are present and let them do just nothing on other entities:
(define-entity-method distance ((e1 entity location1)
(e2 entity location2))
(max (d (x location1)
(x location2))
(d (y location 1)
(y location2))))
You want the implementation of these things?
Here's a paste. (http://pastebin.com/CKMUeAKa) I don't want to make the corresponding repository public yet.
Here's some snippets of stuff not in this file:
(defmacro [a]if (test then &body else)
`(let ((it ,test))
(if it
,then
(progn
,@else))))
(defmacro [a]when (test &body then)
`([a]if ,test
(progn
,@then)))
(defmacro [av]if (test then &body else)
(let ((g!found? (gensym "found?")))
`(multiple-value-bind (it ,g!found?)
,test
(if ,g!found?
,then
(progn
,@else)))))
(defmacro [av]when (test &body then)
`([av]if ,test
(progn
,@then)))
(defun car-or-x (x)
(if (consp x)
(car x)
x))
(defun symb (&rest objs)
(intern (format nil "~{~A~}"
objs)))
(defun ensure-list (x)
(the list
(if (listp x)
x
(list x))))
(defun plist-rem (indicator/s property-list)
(declare (type (or cons symbol)
indicator/s)
(type list property-list))
(the list
(loop for (prop item)
on property-list by #'cddr
unless (if (consp indicator/s)
(member prop indicator/s
:test #'eq)
(eq prop indicator/s))
nconc
`(,prop ,item))))
(defun copy-hash-table (hash-table)
(declare (type hash-table hash-table))
(the hash-table
(let ((newhash (make-hash-table :test (hash-table-test hash-table)
:size (hash-table-size hash-table)
:rehash-size
(hash-table-rehash-size hash-table)
:rehash-threshold
(hash-table-rehash-threshold
hash-table))))
(declare (type hash-table newhash))
(maphash (lambda (key value)
(setf (gethash key newhash)
value))
hash-table)
newhash)))
None of this is in Common Lisp by default. Every programming paradigm you can come up with is implementable in Common Lisp itself in such a way that you can write it intermingled with the more typical Common Lisp. Damn, there are libraries implementing Prolog in Common Lisp – that is, you can write Common Lisp and Prolog in the same file without any external tools, without the need to write a Prolog interpreter or compiler. Just load the library and you're good to go.
Even if you're not going to use Common Lisp or any other Lisp for writing your roguelike, a Lisp is still your best bet for writing your own programming language. Once again, I point you at "Let Over Lambda" and "On Lisp".
In the end, unless you are willing to understand what programming actually is, it doesn't matter which programming language you are working in, you're just going to suck at it. And if you're going to write a programming language without any effort on your part to even understand what others have already been doing, your programming language is going to suck, because you'll make errors that others already made decades ago only because you have no idea why programming languages are the way they are.
Breaking stupid rules is a worthy endeavor, sure, but before that you must understand the rules you want to break.
-
In the end, unless you are willing to understand what programming actually is, it doesn't matter which programming language you are working in, you're just going to suck at it.
I don't suck at programming, you do. Apparently we are not even on the same level here, meaning you are operating on everyday mundane level, thinking that examples you gave are interesting or remarkable, which they are not.
-
I'm not sure whether you're trying to mask your own ignorance or trolling.
What would you actually want to see in the first place? It's kind of strange that you only give off these fuzzy, non-descriptive blurbs about some nebulous ideas that there may be some interesting concepts to make programming more accessible for non-academics, but finding out what such a language would actually look like doesn't seem to be in your interest. I mean, I'm showing you a tool and you berate me for not doing your work for you?
Of course I'm showing you trivial examples!
-
I won't link to it here, but if you take a look at Krice's dev blog you'll get a pretty solid sense of where he's at as a programmer.
-
I won't link to it here, but if you take a look at Krice's dev blog you'll get a pretty solid sense of where he's at as a programmer.
I've reached this stage from another way than I guess "normal" programmers. That's why I can see there is something wrong about pretty much all languages, but I can't exactly say what it is. It's usually something different depending on the language.
-
I'm currently in July'9. The blog is surprisingly readable this far, but there's already a ton of head-scratching going on. How the heck do you design a map generation algorithm in a way that leads to corridor carving being tightly coupled to the rest of map generation?
Word of advice: Problems don't exist in anything itself but only in the relations between things. That is, not the programming languages are flawed, the relation between you and programming languages is.
Of course you'd have a point if there were problems in all relations between programming languages and humans, but I can assure you that this is not the case.
-
not the programming languages are flawed
I wouldn't say that certain things in languages are "flaws", but in case of C++ many things are a result of C++ being ancient. I was just thinking about how I would improve the type system in C++. Some thoughts:
1. Remove ancient types like short, use one type for everything.
2. No 'char' type needed, only string type(s).
3. 'Range' type for integers with automatic limits.
4. 'Unsigned' type for integers (default is signed).
5. No silent type conversions, only through special keyword (+ built-in conversions from integer to string etc.)
6. Type determined from value, no 'int', 'double' etc. needed unless using range or unsigned keywords.
7. Variables const by default, 'var' for mutable variables.
-
That sounds reasonable.
1. Common Lisp has multiple number types, but there is the general type "integer", which is a bignum internally – that is, size of integers is only bounded by memory size.
2. I disagree with this one. Having characters distinct from strings of length one ensures that type checks can be made at compilation time whether setting a single character in a string actually works as intended. What would it mean to set the third character in a string to "foo"?
3. Also in Common Lisp. "(integer -5)" is the type of all integers >=-5. "(integer * 20)" is the type of all integers <=20. "(integer -3000 524)" is the type of all integers x with -3000<=x<=524. Ranges can be made exclusive by wrapping the open bound in parenthesis, like this: "(integer (6))", which is the type of all integers >6. Arbitrary numbers chosen to show that this is not limited to a special subset of numbers.
4. See (3). This also is in C++: Use "unsigned int".
5. I see that this is desirable. When you declare types for variables in Common Lisp, this is enforced. Normally variables don't have types, though, they take just any value you give them. Values themselves still always have types.
6. In C++ you can use the "auto" keyword in place of a specific type. The compiler then infers the type for you. In Common Lisp it's the values that have types, not the variables.
7. Don't know any language that works this way. Haskell is purely functional so mutable variables require a special context either way, but I doubt this is what you want. I hear Clojure is big in immutable structures, but once again this is not about variables being constant but rather the values themselves being immutable. Given that you probably work mostly inside structures and shouldn't tamper around with freely dangling variables that much either way, I think this might be what you're looking for. I have no experience at all with Clojure, though.
-
2. Didn't compute.
3. More like range in Ada: range 1..10 means the integer can be only from 1 to 10. Simple, easy, safe.
4.
a=10; //this is signed int (default)
unsigned a=10; //now we know it's unsigned
6. Why have 'auto' at all? Why not just determine the type? a=10; //int, a=1.0; //floating point, a="string"; //string
7. When you become more experinced and data-driven in C++ you are using const a lot. Why not make it the default for data.
8. Also, I think parameters to functions should be references by default. Probably even const references. I don't think there even should be by value parameters in functions.
-
I'd recommend Common Lisp (of course)
I guess some of these days I should really try Common Lisp or another language that has ridiculous syntax. Just to see if it's actually possible to write any kind of program. At my age it's.. eh.. common to quit stuff if they look like there is some kind of learning curve or barrier to climb over.
I've written small things in Racket (or Scheme, I have some confusion about the difference), which, as far as I can tell, is a descendant of Lisp. All I can say is that it is a strange language. The syntax is all prefix and very uniform, every single procedure call is ([procedure name] [arguments]), which means that nested loops and conditionals cause crap like this : "))))))))))" to close. Annoying without a good IDE, but that shouldn't be a problem today.
For stranger syntax, assuming you haven't already, maybe look into Cat or Forth? I have heard/read that writing your own "forth style" language is fairly easy
http://www.figuk.plus.com/byof.htm
-
3. More like range in Ada: range 1..10 means the integer can be only from 1 to 10. Simple, easy, safe.
Yep, (integer 0 10) is exactly the same in Common Lisp. There's also (real 0 10), for instance, which would include numbers like 2/7 and 0.734.
6. Why have 'auto' at all? Why not just determine the type? a=10; //int, a=1.0; //floating point, a="string"; //string
Don't know. To tell the compiler that a new variable is declared, probably.
I've written small things in Racket (or Scheme, I have some confusion about the difference), which, as far as I can tell, is a descendant of Lisp.
Racket is an implementation of Scheme with various enhancements not in the Scheme standard.
Scheme is a Lisp dialect.
Lisp is not a single language, but a language family. When people say "Lisp" to denote a single language, they probably mean "Common Lisp", although in Lisp circles this is not well-received.
For stranger syntax, assuming you haven't already, maybe look into Cat or Forth? I have heard/read that writing your own "forth style" language is fairly easy
Forth is awesome. Unfortunately I haven't taken the time to really learn it. I think it's not for Krice, though, since it hasn't types at all – at least as long you don't implement them yourself.
-
I just realized that the reason why I'm thinking about a new programming language, along with trying to figure out stuff like prime number theorem and quantum wave function, is that my brain is trying to reach Super Saiyan 2!
-
I just realized that the reason why I'm thinking about a new programming language, along with trying to figure out stuff like prime number theorem and quantum wave function, is that my brain is trying to reach Super Saiyan 2!
So that's why you see the paterns beyond normal understanding!
I wonder if your brain becomes golden when you are transformed...
-
I just realized that the reason why I'm thinking about a new programming language, along with trying to figure out stuff like prime number theorem and quantum wave function, is that my brain is trying to reach Super Saiyan 2!
Weird, most people figure this kind of stuff out in college.
-
Odd. The distinct impression I get from programming languages was that they were created by hacks who only half-understood mathematics - but I love PHP.
-
You could give some kind of example what they got wrong.
-
Floating point numbers. You don't even get a full set of rationals unless you write your own classes. If I were to write a language I'd have all the subsets of complex numbers and matrices as their own datatypes.
-
Rationals are in Common Lisp. Most languages don't bother with them because for a long time they were too inefficient. Also the precision the offer is mostly not needed.
Common Lisp also has complex numbers. Matrices and complex nmbers, as opposed to integers and floats, are not generally useful but only in certain domains. Putting them in the base language looks like overkill. Matrices have the additional problem of not being one but infintely many datatypes, that is, they'd need to be a parametrized data types.
Some programmming languages (not C/C++ though) were also built with the idea of keeping the base language as small as possible. Notably these languages are mostly built by people with an academic background, because building a minimal language requires way more thought and knowledge about mathematics than building one that just already has everything you want built in.
So, when a mathematician builds a language that is made as a programming language instead as a tool for a certain mathematical field, it is more likely to include less constructs instead of more.
-
6. Why have 'auto' at all? Why not just determine the type? a=10; //int, a=1.0; //floating point, a="string"; //string
Python does this. I used to think it was awesome, but it just makes it easier to shoot yourself in the foot during variable reassignments. Sure, it lets you do a free cool things, but I'm unconvinced it's worth the couple of keystrokes saved. Also, typed variables make reading your code almost infinitely easier because it reminds you what that variable is (making it stand out more clearly if you have a mismatch of some sort).
-
Floating point numbers.
I guess the two reasons for that are speed and secondly you can do pretty much everything math related used in real world programs with simple computer math.
-
Also, typed variables make reading your code almost infinitely easier because it reminds you what that variable is
I think these are equally easy to read:
a=1;
int a=1;
In both cases you know it's a integer variable. Type conversions should be strict (using conversion, not just typing a=b), I agree with that.
-
Also, typed variables make reading your code almost infinitely easier because it reminds you what that variable is
I think these are equally easy to read:
a=1;
int a=1;
In both cases you know it's a integer variable. Type conversions should be strict (using conversion, not just typing a=b), I agree with that.
Sure, that's easy to read. But what about with precalculated value?
a = 5*15
// Several lines of code to set up other variables
return_value = a*2
Versus
int a = 5*15
// Several lines of code to set up other variables
int return_value = a*2
These are obviously intentionally brain dead examples because I'm not going to take the time to type fully functional code into my phone. But surely you can see a case this could happen.
-
But surely you can see a case this could happen.
I guess it's a good point.
-
Weird, most people figure this kind of stuff out in college.
Prime number formula:
https://en.wikipedia.org/wiki/Formula_for_primes
I think we have tried to solve this for 2300 years without success. I have an idea, but I haven't had the time to check it out... anyway, I don't even think it's that important.
-
When talking about DIY languages, lisp tends to pop up a lot, and for a good reason. In general, it's good language. In particular, it's great language for writing the language that you want to use to solve a particular problem. Since code and data are interchangeable in lisp, it's a language that is easy to extend to handle features you would like it to have. It's also very simple language. Writing a working lisp interpreter is a weekend excercise (and fun to boot).
There are some features I would like it to have though, one of them being some sort of static typing with inferred types. But I guess I can't have everything, can I?
There's nice set of MIT lectures for Structure and Interpretation of Computer Programs. (https://www.youtube.com/watch?v=2Op3QLzMgSY) It's starts very slowly, from very basic things, but eventually gets to really mind blowing stuff. I often rewatch it just for the sheer fun of it.
Coming up with own language is fun exercise, you should definitely try your hand on it and see what you can come up with.
-
Mind blowing is an understatement for that series. Every time I watch that video series, i feel like everything I knew about computers goes pear shaped.
-
I watched the first part. Besides almost falling to sleep I learned that the students tried hard to look smart, lisp teachers are smug and there was young Bill Gates in the class.
-
I watched the first part. Besides almost falling to sleep I learned that the students tried hard to look smart, lisp teachers are smug and there was young Bill Gates in the class.
;D :-*
On a related note, Humble Bundle has a bunch of programming books for sale currently. Lots of interesting looking titles for languages like Python, F#, Lisp, Erlang and Haskell. And bunch of books that aren't language specific as far as I can tell.
-
Don't remember if I mentioned this but I would probably create a language with just one main paradigm and actually restrict the language having possibility for meta-programming. I can't think any better paradigm than OOP, but it has some problems that could(?) be improved. Maybe you could somehow force OOP to have true modular structure so you could like never access member data directly. I don't know. I think that limitations could make the language actually good, rather than multi-paradigm structure that's breaking everything which leads to confusing mass of source code that in some point will get hard or even impossible to maintain.
-
If the videos are too 1980's for you, consider the book. It's available free online. https://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#%_toc_start (https://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html#%_toc_start)
-
As a side note, I've been watching 0.5 hours of Scala tutorial and that language is kind of cool. The syntax is very nice I think.
-
I a truly in awe of your overbearing competence in the field of programming languages and their use.
-
I have heard quite a bit good things about scala, but haven't programmed with it. It's yet another example how languages are developed and features collected from various other languages. No wonder software development (at least in some areas) is moving towards polyglot culture, where no single language is considered the only viable choice. Keeps your world view fresh too, when you have to pick up new things and try out new features.
-
I a truly in awe of your overbearing competence in the field of programming languages and their use.
Maybe that's why I'd like to create a simpler language, maybe... The "Critisism" section in Wikipedia of Scala mentions that it has a learning curve. It does look like some of the features of Scala are more advanced than I would like myself. But it doesn't mean you have to use those features if the core features of the language are useful enough to create programs possibly easier than in C++.
-
Folks, the first step in creating the ultimate roguelike is to invent a language capable of expressing its majesty,
-
Every language has a learning curve. If there isn't curve, you aren't learning and are merely just hashing old ideas. And that's not particularly productive, usually.
There's also difference between core ideas of language and its syntax. Latter of those requires merely some memorization, while learning the former actually exposes you to new ideas and paradigms. You can pick up OO language and write code that looks very procedural. Or you can pick up lisp and write very object heavy code with factory objects and such. Doing so misses the point why the language was invented in the first place.
I'm repeating myself, but when evaluating a language, one should look past (not completely ignoring though) its syntax and see what are the primitive parts of the language, how you can combine them to create new parts and how do you create abstractions for those new parts you created. Parlor tricks with syntax or esoteric features are fun to talk about, but not particularly useful in evaluating a language.
-
Parlor tricks with syntax or esoteric features are fun to talk about, but not particularly useful in evaluating a language.
I don't think syntax is a trick. For example I don't like lisp's syntax and probably never will. But I need to try some other language than C++. It's not going to be Scala though, since I learned it requires java and I dislike java.
-
Parlor tricks with syntax or esoteric features are fun to talk about, but not particularly useful in evaluating a language.
I don't think syntax is a trick. For example I don't like lisp's syntax and probably never will. But I need to try some other language than C++. It's not going to be Scala though, since I learned it requires java and I dislike java.
Scala very likely does not require Java but the JVM.
-
Scala very likely does not require Java but the JVM.
JVM is java.
-
Parlor tricks with syntax or esoteric features are fun to talk about, but not particularly useful in evaluating a language.
I don't think syntax is a trick. For example I don't like lisp's syntax and probably never will.
I didn't claim that syntax is trick or completely irrelevant. I merely pointed out that parlor tricks with syntax aren't that good grounds for evaluating a language.
One could ask questions like: "does it have objects?", "how are objects built?", "can I combine objects to create more complex objects?"
Or even: "does it have arrays?", "what can I put into arrays?", "can I put arrays in arrays?", "What other datatypes are there?", "How do I combine datatypes to bigger constructs?", "How do I make big blog of combined data to behave in a cohesive way?"
"Can I have subroutines?", "Can I combine subroutines to bigger subroutines?", "Can I pass sub routines around as data?", "Can I create subroutines from subroutines that were passed in?" and so on.
It's ok to not like a language because of its syntax. But it's not particularly good idea to say that some language is superior to other just because of its syntax.
-
Scala very likely does not require Java but the JVM.
JVM is java.
Nope. JVM is the Java Virtual Machine, which is, well, a virtual machine executing byte code. Java is a programming language that is normally compiled into byte code which can be executed with the Java Virtual Machine.
-
You do realize it's executing java code.
-
You do realize it's executing java code.
It's executing byte code, not Java code. Just like a x86 processor isn't executing C code but assembly. Of course the JVM is a virtual machine, so it isn't as physical as a processor, but the principle is the same: Java is compiled into a specific form of byte code that is not Java anymore and executable by the JVM. The JVM cannot execute Java code directly – Java code needs to be compiled first. Just like C code or C++ code or whatever other code needs to be compiled to assembly before it can be executed on the processor with an interpreter.
You know, it's the Java Virtual Machine, not the Java Interpreter.
I despise Java probably a bit more than the next guy. Still, the fact that a language is running on the JVM doesn't tell you anything about the language at all. Prolog is running on the x86 (among other things) and yet it has almost nothing in common with assembly or C.
-
Of course the JVM is a virtual machine, so it isn't as physical as a processor
Actually there is physical processor that executes jvm byte code. Was developed by Sun, before it was purchased by Oracle, but never become even slightly popular.
And latest Oracle Sparc M7 have feature 'software in silicon' which is said to have some built into CPU features that improve performance of JVM.
-
Java is compiled into a specific form of byte code
Yes, it's for java, not for any other language. At least I haven't heard you could compile some other language to java byte code and run with jvm (well, except Scala I guess?). So the java byte code IS java, just in a sort of half-ass-compiled way, slower than pure machine code.
-
Java is compiled into a specific form of byte code
Yes, it's for java, not for any other language. At least I haven't heard you could compile some other language to java byte code and run with jvm (well, except Scala I guess?). So the java byte code IS java, just in a sort of half-ass-compiled way, slower than pure machine code.
"Argument from (personal) incredulity (divine fallacy, appeal to common sense) – I cannot imagine how this could be true, therefore it must be false."
Here's a handy list of languages that target JVM: https://en.wikipedia.org/wiki/List_of_JVM_languages
But I was wondering. If you are after OO language that has similar syntax as C/C++, have you had a look at C#? Pretty familiar language, but has bunch of constructs that make your life easier.
You could write down list of features that you definitely want, would like to have and which would be nice. Armed with that list and internet, your search might turn up some language(s) that could be good candidate for next project.
-
Here's a handy list of languages that target JVM: https://en.wikipedia.org/wiki/List_of_JVM_languages
Yes, yes. But they all become java. There are some languages that "compile" to other languages, I think Ruby (could remember wrong) is strangely compiled to C! And then I guess compiled to executable. Weird if you ask me.
But I was wondering. If you are after OO language that has similar syntax as C/C++, have you had a look at C#?
I don't know if it has to be similar to C++. More like better if it's not.
-
I don't know if it has to be similar to C++. More like better if it's not.
It'll be easier to find when you know what you're searching for. When you find your language, do let us know :-*
-
I wonder if I really have to try Ruby on Windows, because I can't make any sense of installation instructions for OSX. You need like zillion programs already installed before you can start to install Ruby. This is unix/linux style stuff, right?
-
The official page says that you can install Ruby via homebrew like this:
$ brew install ruby
https://www.ruby-lang.org/en/documentation/installation/#homebrew (https://www.ruby-lang.org/en/documentation/installation/#homebrew)
This should install all dependencies automatically.
Are you trying to compile yourself? This almost always requires all kinds of dependencies, even on Windows. The equivalent to using an installer is doing it with a package manager like homebrew.
-
I need to install homebrew? I wonder how difficult it is to install. Maybe first I need to install something else.
-
http://brew.sh/ (http://brew.sh/)
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"Seems you need ruby. ;D
But seriously though, you actually might try compiling yourself. The Ruby page says this about compiling:
Of course, you can install Ruby from source. Download and unpack a tarball, then just do this:
$ ./configure
$ make
$ sudo make install
By default, this will install Ruby into /usr/local. To change, pass the --prefix=DIR option to the ./configure script.
Using the third-party tools or package managers might be a better idea, though, because the installed Ruby won’t be managed by any tools.
No idea whether these instructions work for OS X. There is no mention of any dependencies.
Is make normally installed on OS X?
Actually, OS X supposedly comes with ruby preinstalled. Installing homebrew and installing ruby with that might still be a good idea, though – the preinstalled version is probably very much out-of-date.
-
Java is compiled into a specific form of byte code
Yes, it's for java, not for any other language. At least I haven't heard you could compile some other language to java byte code and run with jvm (well, except Scala I guess?). So the java byte code IS java, just in a sort of half-ass-compiled way, slower than pure machine code.
Java byte code is Java only in the loosest possible definition of that word. You wouldn't look at an executable compiled from a C++ program for a Windows machine and say, "Oh, that was written in Windows. I don't do windows."
It wasn't written in Windows, it was written in C++, it just happens have been compiled against the windows environment. JVM is the same. It's an environment you can compile code against. I can't think of any reason you couldn't compile any language against the JVM environment (though I can think of several reasons why you shouldn't compile done languages against JVM).
JVM allows you to write once, play anywhere. That's why it's a "half-ass-compiled" sort of thing. The local JVM interprets the specifics of X vs. DirectX vs. iDisplay (no clue what apple calls their display suite) or various file system things or other interoperability concerns. It is slower, a fact highly unlikely to matter unless you've implemented particle physics in your game (in which case, don't do that. The world doesn't need 2 Dwarf Fortresses) because it's pretty damn fast. For reference, Minecraft is written in Java. It runs just fine speed wise.
-
Actually, OS X supposedly comes with ruby preinstalled.
Funny, it does. The version seems to be 2.0.0. which is good enough I guess. But when I'm reading the documentation of Ruby it looks like it's a gigantic language. I don't know where to start. Probably just hacking in some classes and trying to create some kind of basic io for a roguelike. Man this is hard!
ps. I wonder what -else- is pre-installed on OSX.
-
I can't think of any reason you couldn't compile any language against the JVM environment
Well you can't. Unless you write a compiler to compile C++ (or whatever) to Java first.
-
I can't think of any reason you couldn't compile any language against the JVM environment
Well you can't. Unless you write a compiler to compile C++ (or whatever) to Java first.
The code run by the JVM is not Java. It's bytecode that has exactly nothing in common with Java at all. The only connection they share is that Java was the first language to be compiled into that form of bytecode. So no, you don't need to compile anything to Java to run it on the JVM.
-
The code run by the JVM is not Java. It's bytecode that has exactly nothing in common with Java at all.
Read the first line of text in Wikipedia:
"A Java virtual machine (JVM) is an abstract computing machine that enables a computer to run a Java program."
..to run a Java program.
..a Java program.
..Java..
-
The code run by the JVM is not Java. It's bytecode that has exactly nothing in common with Java at all.
Read the first line of text in Wikipedia:
"A Java virtual machine (JVM) is an abstract computing machine that enables a computer to run a Java program."
..to run a Java program.
..a Java program.
..Java..
At the end of that same pararaph:
An instance of a JVM is an implementation running in a process that executes a computer program compiled into Java bytecode.
a computer program compiled into Java bytecode.
compiled into Java bytecode.
Java bytecode.
bytecode
So, what's Java bytecode (https://en.wikipedia.org/wiki/Java_bytecode)?
Java bytecode is the instruction set of the Java virtual machine. Each bytecode is composed of one, or in some cases two bytes that represent the instruction (opcode), along with zero or more bytes for passing parameters.
Hmmm… One or two bytes per instruction. Somehow that doesn't sound like Java at all, since Java isn't instruction based. I think the language doesn't even have a concept called an "instruction".
Also:
A Java programmer does not need to be aware of or understand Java bytecode at all. However, as suggested in the IBM developerWorks journal, "Understanding bytecode and what bytecode is likely to be generated by a Java compiler helps the Java programmer in the same way that knowledge of assembly helps the C or C++ programmer."[2]
Seems the relationship between Java and Java bytecode is roughly the same as the relation between C++ and Assembly.
Here's an example of Java bytecode in human-readable instead of binary form:
0: iconst_2
1: istore_1
2: iload_1
3: sipush 1000
6: if_icmpge 44
9: iconst_2
10: istore_2
11: iload_2
12: iload_1
13: if_icmpge 31
16: iload_1
17: iload_2
18: irem
19: ifne 25
22: goto 38
25: iinc 2, 1
28: goto 11
31: getstatic #84; // Field java/lang/System.out:Ljava/io/PrintStream;
34: iload_1
35: invokevirtual #85; // Method java/io/PrintStream.println:(I)V
38: iinc 1, 1
41: goto 2
44: return
Huh, it doesn't even look like Java at all.
Being a self-taught Cowboy programmer is nice and all, but if you're missing formal education you'll have to be more careful when reading and talking about stuff you're new to.
-
I'm sorry, it still requires a language that can be processed by the JAVA vm. You know, not all languages are compatible with JVM.
-
Any given language can be compiled into Java bytecode if you write a compiler that does it. There is no arcane barrier that prevents you from writing a compiler for compiling C, C++, Common Lisp, Scheme, Haskell, Prolog, Forth or any other arbitrary language into JVM bytecode – there is no need to use a detour over a compiler that first compiles into Java. It's probably about as hard as writing a compiler which compiles any of these languages into x86 or x86_64 or whatever other assembly.
Yes, there aren't compilers for all languages into Java bytecode. Just as there aren't compilers for every language into C or Assembly. That doesn't tell you anything about the language, though.
What a language compiles (translates) into is not a property of the language but of the compiler used. If a given compiler does not exist, you can write it.
-
Whatever.
Anyway, let's move on to more interesting things. I finally decided to update Visual Studio to Community 2015. It has a language called F# (with some other languages as well) which seems to be quite funky. It appears to be leaning to functional programming, but has also classes. Interestingly it has values default as immutable, the way I would also prefer and you have to use mutable keyword to make them mutable. You don't have to specify a type, but you can. Also I like the clear distinction between 'structure' and 'record'. And I don't have to desperately try to find IDE for it like it's with all those open source languages.
-
But.. it's slow. Seriously. I can see the 80x25 level printing on console, it's that slow. I tried to replace Map with simple array (for tile glyphs) and use Console.Write instead of printf, but there was no difference. At least it looks like console programming is out of the question. I wonder how easy it is to go graphical on F#.
-
But.. it's slow. Seriously. I can see the 80x25 level printing on console, it's that slow. I tried to replace Map with simple array (for tile glyphs) and use Console.Write instead of printf, but there was no difference. At least it looks like console programming is out of the question. I wonder how easy it is to go graphical on F#.
Easy as eating a pie. Just pick your favourite .Net graphics library and go wild. I found MonoGame (http://www.monogame.net/) both easy and fast. For console stuff there's MonoCurses (https://github.com/mono/mono-curses/).
-
Easy as
I think you need to install some kind of Git Shell, or what it was called, and compile from source. Hard?
-
Easy as
I think you need to install some kind of Git Shell, or what it was called, and compile from source. Hard?
For MonoGame? Just use nuget-packages from nuget.org (https://www.nuget.org/profiles/MonoGame) and you're set. Bonus points for being ready to update to a newer version when it gets released.
-
use nuget-packages
Hard?
-
For MonoGame? Just use nuget-packages from nuget.org (https://www.nuget.org/profiles/MonoGame) and you're set.
People on reviews of that.. thing seem to be UPset rather than set.