Toy this, toy that

I notice you smart CS types speak of toys. Toy compilers, toy languages. Is there some consensus as to what it means? At what point is something in programming *not* a toy?

Toys are hobby projects. It's no longer a toy as soon as you do it for serious and/or money.

Toy programming - You can't write something that would be a a part of mainstream OS or enterprise network. You program for hobby/project of personal value, not intended for consumers.
Languages which support toy programming can be used seriously, but they would be inferior to using system/enterprise/business solutions due various reasons(such as tech support, updates, etc).

Toy OS - Hobby project that seeks to provide OS features via personal development(small team or often singular author) and small userbase(often programmers).
Toy OS with sufficient mainstream support becomes a normal OS.

There no toy languages per se, there toy programs and and paradigm of "toy programs/novelty program" which is answered best by some languages. Brainfuck could be used to write an OS.

toy's not a toy bud, grow up and leave

The only consistent definition is "Whatever the person saying it doesn't like"

Assembly is a toy language, like brainfuck, just using more of hardware features. Prove me WRONG.

>>7
One word Lisp thread over.

Toy languages have several defining characteristics:

1. Poor library support.
2. Obstacles that prevent real world usage e.g.
- Buggy/immature implementation
- Poor performance, especially for critical things like I/O
- Difficult to program in
3. Little adoption by for-profit or notable non-profit organizations
4. Unorthodox language features.
5. Cult-like user base

>>9
Cult-like user base
That one could be said of every language.

>>10
Cognitive Dissonance. Great name for a new language.

"toy" is a useless adjective that people like to give their projects

hey guys check out my light fast tiny simple unicode-ready toy language compiler / interpreter built with llvm (my favorite toy project)

Toy usually means its just for fun/practice/experimentation. Each of these things has great value to the programmer.

>>8
I'll take CL as an example and prove that it doesn't fit >>9's definition:
1. Poor library support.
No, there's plenty of libraries - I've yet to encounter needing a general purpose library which I couldn't find. In recent CL applications I've written, I've used 4-5 libraries per project. Minor bugs were encountered on some older ones, but fixing the bugs myself only took >30min of debugging time total.

2. Obstacles that prevent real world usage e.g.
- Buggy/immature implementation
Some implementations have 10-20 years(or more) of development behind them. Most are pretty damn stable and mature.
- Poor performance, especially for critical things like I/O
Almost all real ones generate native code. Some can approach C in levels of performance if used with enough declarations. 2-4 times slower than C is common when one doesn't optimize/profile, but that's still much better than some other languages.
- Difficult to program in
3. Little adoption by for-profit or notable non-profit organizations
What does adoption have to do with difficulty of programming in? It was adopted in the past by the US govt and various corporations (Symbolics even made an entire OS in it), but due to mismanagement and the AI Winter, usage drops. It's still in use by various companies, some quite large, but it's most certainly not a mainstream language.
4. Unorthodox language features.
What does ``unorthodox language feature'' even mean? Do you consider the C pointer unorthodox? Do you consider the Java class unorthodox? Do you consider direct memory access in assembler unorthodox? Do you consider passing functions as arguments (first-class functions) in a language unorthodox? Do you consider VHDL/Verilog's timing model unorthodox? and so on.
Language features are what define a language. There's no such thing as orthodox or unorthodox, unless you mean that anything that isn't just a strictly imperative language as unorthodox, but even if you consider that, most languages, even popular ones, don't fit that model exactly. Lisp's features usually take advantage of the S Expression based notation to achieve macros, read/write representations, first-class functions, list templates and so on - they are what define the language.
5. Cult-like user base
A bit confused what this is supposed to mean. I'm willing to go for what >>10 said, but I'd imagine anyone has some favorite language (be it C, Java, Perl, PHP, Haskell, Scheme, CL, etc), so it probably applies to any language. Lisp does have a few separate userbases which keep it alive by maintaining implementations and writing libraries (most BSD/MIT, public domain, and a few LLGPL(more permissive LGPL)).

Oops, I forgot my IHBT

I agree most with:
Toy usually means its just for fun/practice/experimentation. Each of these things has great value to the programmer.

>>14
I started a point by point response to your post, but then I realized you're either a retard or trolling so I stopped.

>>17
I won't fall for your meta-meta-trolling.

Non-toy languages have several defining characteristics:

1. Good library support.
2. Several features that encourage real world usage e.g.
- Bugfree/mature implementation
- Good performance, especially for critical things like I/O
- Easy to program in

3. High adoption by for-profit and notable non-profit organizations
4. Most language features similar to other non-toy languages.
5. Large user base with a variety of opinions about the language.

Where does CLisp fit in? Somewhere between toy and non-toy, closer to the toy side.

>>18
You just fell for it

CLisp is an implementation not a language IHBT

>>19
CLisp (GNU CLISP implementation of Common Lisp) is somewhat average, it's probably one of the slowest CL implementations since it's interpreted (but it does have a JIT). There are other implementations with much better performance overall (SBCL, ClozureCL, the commercial ones, etc).

1. Good library support.
I don't think it has as many libraries as C or Java has, but I have yet to not find a library that I needed, and usually with a decent license too (public domain, BSD/MIT, LLGPL are very common, so you can even use it in proprietary products if you really want to). My only problem is that not all libraries are that well-maintained, so you might end up having to fix a bug here or there, if you encounter any, but usually this isn't a huge problem for anyone knowing the language (I found debugging CL code to be rather easy, especially with the available debugging facilities).
2. Several features that encourage real world usage e.g.
- Bugfree/mature implementation
Most implementations are standards compliant and pass the ANSI tests. They also have quite a few extensions beyond ANSI (gray streams, MOP, sockets, inline assembler, threading, debugging facilities, etc).
- Good performance, especially for critical things like I/O
This varies. Most implementations compile to native code and they have decent performance. SBCL generates good code, but the compiler is slower. ClozureCL generates average code, but has a fast compiler. CLISP is interpreted, but it also has a JIT, it's probably the slowest. ABCL is okay, runs on the JVM, so about as fast as that, plus some overhead. Then you have the commercial ones: LispWorks, Allegro CL, Sceineer CL, Corman ...
They compile to native code, and some have an interpreter as well. They differ in what the implementation offers (mostly ENTERPRISE libraries(CORBA for example, or object databases/persistance (there's free alternatives for these of course)), very good threading support, and so on)
- Easy to program in
I find it easy to program in, and I find my code maintainable. The problem here is that a lot of people have problems learning the language to begin with and getting over initial hurdles. Getting the tools and environment set up is also a problem for some people. I've set up implementations on Windows and Linux before without any issues. I've seen people use them on OS X too.
3. High adoption by for-profit and notable non-profit organizations
I wouldn't say so, but there are companies whose likelyhood depends a lot on it. Notable examples are ITA software and some knowledge-base companies. I still believe it's mostly a niche language, but it does receive some commercial support. Free implementations ocasionally have people have for support(ClozureCL and SBCL mostly), and commercial ones offer it for free or for pay.
4. Most language features similar to other non-toy languages.
It has the same features as imperative languages have, and much more (feel free to add your own language features, or make up your own domain-specific languages if you feel the need. Extending the object-system to match your needs is also easy).
5. Large user base with a variety of opinions about the language.
The userbase isn't large, but it's not small either, there are plenty of libraries, and the implementations are mostly well maintained. I'd say it stikes a decent balance - enough to keep the language alive and usable, but not enough to have your libraries store 100 of those silly "Learn Common Lisp in 24 hours" books.

s/have people have/have some people pay//

>>19
You're implying that every language gets born a ``toy''. And thus even Godly C would have been a mere ``toy'' at some time.

No language or tool became universally adopted overnight. I'd rather define a toy language as one that is just too stupid, utterly inefficient/bloated or attempts to serve too many masters, no matter how widespread it is. Of course this definition was especially made to have Python match it.

>>5

Oh wow, I never thought I'd see that in here.

Not even being sarcastic.

>>24
7/10. That's some serious shit you've got going there, dude.

>>24
Godly C was a Godly BCPL-derivative. And so on. At one point people thought even assembler was a pointless simplification. So yeah, even C was questionable at one point, but not nearly so as the majority of languages.

>>27
assembler
Good to see they've moved on to compiler, then. Moron.

>>28
AMERICA FOR PRESIDENT.. MORAN!!

Assembler is a typical toy language:
1. Poor library support.
2. Obstacles that prevent real world usage e.g.
- Buggy/immature implementation
>due being overtaken by compilers, assemblers are marginal niche now.
- Poor performance, especially for critical things like I/O
>unless you you know the best algorithm, implementing them in ASM in a naive way will show how fast it is(SPOILER: worse than C).
- Difficult to program in
3. Little adoption by for-profit or notable non-profit organizations
4. Unorthodox language features.
5. Cult-like user base

>>30
``Assembler'' isn't a language at all. Please review >>28.

>>30
Huh. You're trying too hard but I'll have to give it to you - by the measures established in this thread assembler sure does resemble a toy language.

>>30
1. Poor library support.
Stopped reading right there. IHNBT.

>>33
Or have you? Or have I?

>>33
Assembler library support is like government support for human rights in China. They pretend to import every human right but try to squeak louder and your off to labor camps.

>>35
If you can use a library in C, you can use it in asm.
It's just native code. I'm not saying you won't have to put some effort to get calling conventions right, set up stubs, whatever, but if you want it, you can use it.

>>36
I find it alarming that C programmers often misunderstand this.

>>36
I don't understand this post.

Don't change these.

Name:		Email:
Entire Thread Thread List