Omnimaga
General Discussion => Other Discussions => Miscellaneous => Topic started by: Binder News on May 21, 2011, 10:30:39 pm
-
What are some things you like/dislike about a language (Java, C#, Fortran, Groovy, C++, C, etc.)?
Please list the language, then what you like about it.
EDIT: I'm talking more about language features, not speed (that's an implementation issue).
For example:
Java:
like:
-garbage collector
dislike:
-garbage collector runs when you don't want it to
-
Axe
Like:
Fast and portable.
Dislike:
Not as much control. (Can't wait for Axsembly!)
C/C++
Like:
Low-level.
Dislike:
Inconsistent syntax.
Java
Like:
Strict syntax. (Some people love it, most people hate it.)
Dislike:
Strict syntax. (Ditto.)
Javascript
Like:
Intuitive once you get the hang of it.
Dislike:
Syntax too wordy without jQuery.
jQuery
Like:
Compatible, consistent, and elegant.
Dislike:
Slow.
Lua
Like:
Cross-platform, fast.
Dislike:
Tables. (I'm still stuck in the OOP paradigm.)
PHP
Like:
Widely accepted web programming.
Dislike:
Very slow, inconsistent, and too trapped by its own backwards-compatibility (the same problem as C++).
Python
Like:
Extremely intuitive and elegant.
Dislike:
Slow.
TI-BASIC
Like:
Portable.
Dislike:
Slow, highly constricted (on Nspires).
Windows batch
Like:
Convenient.
Dislike:
Structure and syntax quirks. (What? They actually force me to use GOTO?)
Z80 assembly
Like:
Low-level.
Dislike:
Too repetitive in some ways.
-
Python:
Like:
-Clear organization
-modules
-easy to learn(relatively)
dislike:
-slow(relatively)
-not as easily portable as some other languages
C/C++
Like:
-easy to see the organization
-FAST
dislike
-semicolons/braces
-having to declare variables
-
Okay, thanks. Now, let's say speed is irrelevant. I'm talking more about language features.
For example:
Java:
like:
garbage collector
dislike:
almost no control over the garbage collector
the internal workings of Java itself allocate memory, (seriously. I have a program where ALL the memory is allocated at the start. All other allocations were from Java class library calls.)
-
bump
-
SuperH Assembly:
Likes:
Instructions are a constant two bytes large.
Most normal operations have dedicated opcodes.
Single cycle execution time for all by a handful of instructions.
Simple syntax.
Highly backwards compatible.
Powerful.
Dislikes:
Certain important operations, such as MOV.L @Rm-,Rn aren't supported.
It takes a lot of code to do non-trivial things.
The division opcodes are extremely difficult to use efficiently.
Too few registers.
x86/x64:
Likes:
Powerful.
Hardware support for pretty much every function you could reasonably desire.
Large number of available registers.
Dislikes:
Slow execution of many instructions.
Inconsistent and highly variable instruction size.
Branch execution is very difficult to optimize.
The "standard" x86/x64 instruction set is badly defined and many different variants are floating around.
Axe:
Likes:
Fast.
Fairly powerful.
Makes greyscale simple.
Dislikes:
Often not as efficient as pure z80.
The syntax is too strict.
Java bytecode:
Likes:
Powerful.
It's an elegant language.
Dislikes:
Some of the instructions are annoyingly complex and the garbage collection means that you have to be careful with your pointers.
Slow (unless interpreted by hardware).
CIL bytecode (.net):
Likes:
It's limited Turing complete.
Dislikes:
Slow, complex, and garbage collection.
-
Humm. Ok, well I guess that's useful. Just please keep in mind, that I'm really talking more about higher-level language features (ex garbage collection, synchronized blocks, const). But I guess lower-level stuff can be useful as well.
-
Axe
Likes: It actually has a pretty loose syntax, and is pretty powerful and extremely easy to code in.
Dislikes: Its variable system can be limited at times and makes you have to use pure pointers very often, and the principle of least surprise isn't seen at all: code written by a newbie can be hard to understand sometimes -- unless you wrote the code, good luck trying to decipher it.
z80 assembly
Likes: fast, and with a good assembler like Brass or SPASM you can get away with murder in many cases.
Dislikes: extremely strict syntax for many instructions, and many instructions you would think would be supported, aren't in most cases.
C
Likes: very fast, and like Axe can have a nice, loose syntax.
Dislikes: strict procedural rules and like Axe, the Least Surprise ideals are missing -- if you skip over one line of code, you might not understand the entire thing.
C++
Likes: adds OOP to C
Dislikes: a horrible implementation of OOP.
Python
Likes: very intuitive, and actually pretty fast for an interpreted language.
Dislikes: not as flexible with lambda statements and block coding.
Ruby
Likes: Beautiful syntax that builds upon python's, very easy to read and code can be extremely loose and condensed at the same time. Plus, great handling of lambda statements and blocks.
Dislikes: lower-level things can be very slow, but it beats python for speed if you use the YARV or JRuby frameworks.
Ada
Likes: a C-like language with much more flexibility and better syntax
Dislikes: not as many people besides the government use it, so it's hard to find as many modules/libraries for it.
Java
Likes: a decent approach to OOP, definately beats C++'s by a long shot, and many more OOP features than many other languages
Dislikes: horrible syntax, too high level and low level at the same time, since it supports primitives AND high level objects, which can lead to stupid code
Groovy
Likes: Java done right.
Dislikes: not many. Maybe just things not having to do with actual code, like the pain you go through just to set up a project correctly and make it work with Java resources.
D
Likes: a bit of an improvement on C++, with more flexibility with objects and polymorphic code
Dislikes: still has horrible OOP like C++
Javascript
Likes: I really don't like anything about it
Dislikes: where to start? Horrible syntax, horrible fake OOP is fake and horrible, pretty slow, and most applications require a lot more code than other scripting languages
Lua
Likes: it's form of 'OOP' (I use that loosely) -- it's extremely flexible and fun to write in, and is pretty decently fast
Dislikes: not that much module support, and the standard debugger really sucks at supplying feedback
-
Oops, forgot to add these:
Prolog:
Likes:
Code tends to be compact.
No more difficult problem solving.
Dislikes:
Compilation is incredibly slow...
TI-84+ BASIC:
Likes:
I wish every HLL was more like TI-BASIC. The syntax is beautiful and the math support is arguably better than many "normal" languages or other forms of BASIC.
The IDE is also excellent, missing only Copy and paste.
Dislikes:
Somewhat slow and the interpreter can sometimes bug out, requiring a reset.
-
Ok, I still would like more people to comment please...
-
TI-83+ BASIC
Likes: Fast to program, easy to learn and code, smaller executable code, relatively stable
Dislikes: Slow, massive data size (a list element takes 9 bytes for example), less control on the calc
Axe
Likes: Fast to program, somewhat easy to learn if you already know TI-83+ BASIC, not too hard to code, small data size, programmable on-calc, runs very fast and gives more control on the calc, very easy to perform graphical stuff
Dislikes: Error usually means crash and data loss, large executable code size, hard to use external data, not as much control on the calc as ASM
ASM
Likes: The fastest language for calcs, total control on the calc, small data size
Dislikes: Error usually means crash, larger executable code size than TI-BASIC in certain cases (unless you use bcalls), major hassle to learn and takes forever to code large games.
-
Okay, I'm reviving this topic, and changing it a little. What features would your perfect programming language have?
-
- A good IDE (whether it be notepad++ or a dedicated IDE).
- A simple compiler/interpreter (IE, press a build button and enter in the name of the output file).
- Very simple syntax. The mark of a well designed language is that a beginner can understand it without much work, but an expert still finds it useful.
- Easy screen access for GUIs.
- Fast execution time.
- Low level access for those non-standard things.
- No Objects. The language also has to be Imperative.
- Extensive math/string capabilities.
-
Why no objects?
-
Because they make the code more confusing than it needs to be. Black boxes are something you should be trying to avoid, not create, especially within the program itself. The useful features that objects do provide can easily be synthesized through argument passing.
-
What are black boxes?
-
What are black boxes?
You don't know how it works, only that it does. Until it doesn't, at which point you don't know how to fix it.
-
Mine?
- Object Oriented Programming to the Max, though with improvements on the Inheritance system and in turn a Instance Grouping System
- Quick Debugging
- Syntax that makes sense, but no use of symbols except {},|, etc. for code blocks and "." for object <-> member access
- Functional at the core
- Extensive math/string capabilities
-
Oh. I've had one or two of those.But that can happen in any language regardless of whether or not it is OOP.
EDIT: What's in instance grouping system?
-
The thing about Objects is that you're not supposed to really understand or care how they work, just what they do, which is why I called them black boxes.
-
Your're not supposed to really understand or care how compilers work either. Are they Black Boxes?
-
Your're supposed to really understand or care how compilers work either. Are they Black Boxes?
Well, you're supposed to know how some compilers work -- good Java programmers know how to make their own building setups with the jdk, and C programmers better know how the compiler works if they're going to be doing something that isn't a game or a "hello world" program ;)
-
Your're not supposed to really understand or care how compilers work either. Are they Black Boxes?
In a way. Ever watched someone try to fix a bug in a compiler that's not theirs :P
Objects are worse because
A) They typically don't have as much debugging time invested in them as compilers do
B) Generally aren't written by coders at that level (compiler design is generally considered somewhat of a black art.)
C) Are present *in* the code code itself, whereas the bug(s) in the compiler may or may not even be relevant to whatever program you're compiling.
-
Yeah, but it's the same way with Objects. You know a little bit of how they work. And what is an Instance Grouping System?
EDIT: I still like objects, but I guess you shouldn't be forced to use them. What about JIT stuff? Yea, or Nay?
-
And what is an Instance Grouping System?
Kinda something I just made up with Verdant. Basically, a group takes the role of providing inheritance (with a supertype defining what all group instances will extend) and Interfaces (a group design basically is the same as a Java interface, but more flexibility of contents). I personally think my method of Grouping is a lot better than normal OOP in some respects.
-
JIT is wonderful for interpreted languages. Yea!!!!!!
The only problem with it is the lack of support for SMC when it's used.
-
Define SMC please.
-
Self-Modifying code. Code that changes as it's run.
SMC can be extremely memory efficient (and speed efficient if Caching isn't used). For example, using SMC in Branf*ck allows a memory space of only 270 cells to be turing complete
-
"Self-Modifying Code"
I should have remembered. I just forgot that was what the acronym meant.
-
One thing I recently discovered about Java is that it doesn't allow tail-call optimization, meaning you cannot use recursion to make loops without worrying about running out of memory. This contrasts to some languages like Scheme which require it as part of the language specs. Just something I thought was interesting...
-
Huh. That is interesting.