i'm gonna group quotes together to help address all points
I've taken 3 semesters of C++... I'm interested to see what implementations you're pursuing.
lol what does that mean
some flaws with java are with the semicolons and ( [ { are annoying as hell. visual basic is better but we copied more code out of books. like everyone got an a if you tryed so i liked programming class. the best part was making a 7 card stud game though it took a couple weeks
what? i'd rather steer this discussion away from CS 101.
--------------------------------
What languages have influenced sly the most, both positively and negatively? What sort of things have you drawn from those influences?
In addition, what sort of "paradigm" do you see sly fitting, if any? (ie functional, logic, imperative, whatever).
Good question! I think this is the best way to start this post. Sly is a statically typed multi-paradigm language with type inference. I guess for the most part you could call it "functional" - but in reality, it joins together the benefits of all the concepts in a way that is consistent and elegant. I almost feel bad calling it "OO" since people conjure up thoughts of C++, Java, etc, but it is an advanced OO language as well. I'll show examples of what it looks like later on in this post, and why it's actually something to be excited about.
Positive influences:
Haskell - Haskell is, in my opinion, the best designed functional language out there. If you're looking for a pure functional language, go for Haskell, not Sly. Unfortunately, monads, in my opinion, are a bit of hack. The pure functional language concept is a great dream, but in reality it is too impractical to separate state from the language. Since Sly tags functions as pure when possible, it has the same theoretical advantages of a pure functional language, such as aggressive optimizations and the ability to parallelize algorithms with little effort but without the awkward separation of state from the core.
Python - What Smogon is written in. One of the most readable languages I've ever encountered, using indentation for grouping is genius. The philosophy of Sly has a lot in common with Python ("there should only be one obvious way to do it", "readability counts", "batteries included", etc). Some of the syntax is derived from Python as well. In addition, some of the "generator" concept is taken from Python as well but with a few changes here and there.
Lisp - Lisp doesn't try to baby the user, which I appreciate. If I learned anything from Lisp, it's that you should empower, not restrict. Morons can write bad code in any language. Just try not to _encourage_ it like Perl does.
Negative influences:
C++ - C++ has a few unique problems with it: it's slow to evolve, the language comes with little in the way of libraries, and it tries to bank on C's success. I am trying to avoid all of those.
Java - A language created for medium-level programmers that tries to shoehorn everything into an OO concept. The result? Too much verbosity. Sly is for the most part, the anti-Java.
Perl - Perl is cool as a text processing language. I am dissapointed that it evolved into being the kitchen sink :( I take Python's stance - Perl has all of the readability of an '08ers post, and that should be avoided at all costs. Sigils are stupid, too.
Lisp - I love the concept of Lisp, I just don't think it's practical. Prefix notation is verbose at times and the deep nesting of parens is hard to grok. Macros aren't worth it. In addition, the Common Lisp standard isn't evolving at all and most of the stdlib feels dated (lack of sockets, anyone?).
Here's what I've drawn:
* A language shouldn't restrict its audience.
* Semicolons and braces suck.
* Single dispatch, baby OO languages (think object.method() on everything) are impractical for large projects.
* Lisp style "no syntax, just parens" doesn't jive well. Syntatical impurities provide hooks for the eyes and make scanning large blocks of code easier. In addition, it's important to limit the amount of nesting. Humans aren't computers.
* Don't encourage sloppy programming, but don't make arbitrary hoops for programmers to jump through.
* Dynamic typing can be a boon for large projects - what's needed is a static language that feels like a dynamic one. i.e., don't worry about types, but if you fuck up the compiler will tell you instead of waiting a year for a subtle bug to pop up.
* Lazy is GOOD. Python and Haskell encourage this quite a bit. We go a bit more on the Python side as far as implementation of lazyness.
* A lot more!
hats off on the open source bit. there were plenty of things that i wanted to ask, but i guess a good start would be to know the noticeable features of the language, with some examples of syntax.
Anyhow, what would be a good language to compare Sly with in terms of syntax. I guess what I mean is like how Ruby has a similar syntax to Perl.
Syntax? Python meets Haskell. No object.method() nonsense. I'll give a few examples:
------------------------------------------------------------------------------------
Code:
# Print everything in an iterable of strings that has "big steelicks" somewhere in it.
steelicksfinder(i) = filter(find(, "big steelicks"), i)
# Lets use it... in many ways!
people = ["chaos", "big steelicks sucks", "big steelickssssss"]
steelicksfinder(people) # big steelicks sucks, big steelickssssss
f = file("dumb story.txt")
steelicksfinder(f) # Go through dumb story.txt, and select every line that has big steelicks in it.
# Hmm? A basic coroutine that yields nonsense.
dumbfunction() =
while: # while w/o argument is an infinite loop
yield getrandomstr()
steelicksfinder(dumbfunction()) # years later, hopefully this generated some big steelickii!
One of the main features of this language is it's unique type system. As far as I know, it has the most powerful static type system in existence. Types are first class - you can manipulate the signatures of functions at compile time in arbitrary ways. What about a function to reverse an arbitrary sized tuple? The signature kind of looks like this: (syntax hasn't fully been decided on)
Code:
reverse{TL}(tuple{.. TL} t) -> {
R = []
for T in TL:
R = T + R
R
}
Try doing that with Haskell. In addition, compile time analysis is possible as well. Regular expressions can be compiled at compile time, printf can be type checked, etc.
The type system is designed specifically around the application of functions. While Sly is technically an OO language, it surely doesn't feel like one. Lets try an example:
Code:
# In Python, strings have a predefined list of "methods".
# Hey, I want to strip a string!
print " Shut up ".strip()
# Hey, I want to split this string, and strip the parts.
print " Damb | Dooo | Cat ".split_strip("|") # Hell no!
def split_strip(s, sep):
for item in s.split(sep):
yield item.strip()
print list(split_strip(" Ok | Dumb | Example", "|")) # ok, here we go
Why should strip() be any more privileged than split_strip? They both are just functions that operate on a string. Why the difference? This is one of the problems found in todays "OO" languages - only predefined functions ("methods") may take advantage of the privileged syntax and other benefits that come along with it (virtual dispatch). With Sly, and multimethods, anyone can write a function that works on your data and it will look just like every other function - no more, no less.
One of the big advantages of this is that verbose "interfaces" aren't necessary (Java anyone?). Since an interface is defined by the functions it supports, why not just specify a type that supports those functions? In Sly, there is no "inherits Comparable, Cloneable, ...". Define the function it supports with that type, and the deed is done. Perhaps an example is in order.
Code:
# Define an object with length.
len(MyObject mo) = 3
len([1, 2, 3, 4]) # 4
len("cat dog") # 7
len(my_object_here) # 3
# Okay, we need a type that supports the length "interface". Do we make a separate interface and define that function in it?
# No! Boilerplate sucks.
T with len(T) -> int a_variable = (... some object that has a length ...)
Technically, the type declaration isn't even necessary, it has only been provided for examples sake.
Okay, I haven't even addressed syntax. Whitespace is signifigant - as you have seen. Indentation is used for grouping. However, whitespace within a line is also signifigant. All popular languages include the concept of "operators" - i.e. a + b, i - v, etc. The problem with infix operators is of course, precedence. Some languages don't allow arbitrary operators to be defined (which is restrictive), some allow people to define their own operators with their own precedence (which makes parsing a hell ride, and can also confuse the users) and some dont allow overloading at all (which is balls.).
The worst example I've seen is Smalltalk, which uses infix notation for all operators, but makes them have no precedence. The result? Parens hell. The biggest advantage of infix, aside from familarity, is the ability to describe expressions concisely. (a + b) == (c + d)? No thanks. That's just as bad as (== (+ a b) (+ c d)). So what to do? Use whitespace for grouping!
Yes, Sly allows you to define any operator you want for the most part, infix and prefix. Operators are just functions - there is nothing special about them except syntax. We define precedence by the whitespace surrounding them! This makes things easy to parse for the computer AND the human and still allows people to write concise expressions :)
Code:
a + b * d is parsed as (a + b) * d
a + b*d is parsed as a + (b * d)
a+b == c+d # Example above.
+(MyObject a, MyObject b) = 5
my_object + my_object2 # 5
**&(MyObject a) = 8
**&a # 8
Okay, I'm growing exhausted. That's enough for now. The main thing to get out of this is that Sly is an extremely powerful language, and being statically typed can save the programmer from errors and achieve C-like speeds :)
------------------------------------------------------
Even extremely similar languages like Java and C# are very different when you begin to program in them, let alone those languages that push your thinking to the next level.
I disagree... languages that share a paradigm are almost interchangable... the only difference is in libraries.
Not imperitive (C, Pascal, etc.) but Functional. Functional are languages like Lisp, Scheme, and Haskell. Lisp/Scheme can also fall under "symbolic computation" but lemme not rant on that :-p
Are you trying to lecture me on paradigms? ;-( Lisp isn't a language - it's a group of languages. Scheme is a functional Lisp, yes... (I think you're referring to Common Lisp, but that isn't a functional language in any way.)
Objective C is nice OOP (i'll try out Smalltalk eventually...)
Both of them are basic OO languages and not really worth your time. To be fair, there are very few advanced OO languages out there (CLOS, Dylan and Perl 6 are the only ones I know off the top of my head).
i'm aware of the several flaws with the two programming languages i'm fluent with, namely PHP and Visual Basic, and some flaws of C, which i'm not too fluent with. but it would be really nice to have an expert criticism on these languages, especially C since i have been rigorously studying it for the past few months in my free time.
Or are you looking at it from more like a C++, Java sort of thing. An attempt to "do it right" damnit for once?
The problem with the non-C languages here (Java, PHP, Visual Basic) is that were made specifically for "medium level" programmers. PHP got adopted quickly because it was _simple_ (it overtook the infinitely more powerful Perl for top web-development language). The PHP developers know about its shortcomings and they don't address them because they also know their target audience. I'm sort of pressed for time at the moment, but I think
http://www.bitstorm.org/edwin/en/php/ will provide enough rationale for why PHP blows :) (It's one of my least favorite languages :()
Java anyone? It was marketed as a competitor to C++ with features cleaned up. By that, they mean they removed all of the power the language had with templates and operator overloading and tried to pidgeonhole you in its overly restrictive type system. The biggest problem I have with Java is that it tries to bank on the whole "OO works for EVERYTHING! ! !" bandwagon. Not everything is best represented by a class. I get sad when people describe Java as a "true OO" language as well - not only does it make the distinction between primitives and objects, but it also doesn't support advanced OO concepts (unless you consider "design patterns" advanced). Unfortunately, it falls short of being a competitor to C++ - not only is the latter faster and better supported by C libraries and native system services, it provides everything Java does and more.
The biggest problem I have with both is that they are unnecessarily verbose. I don't have time for boilerplate!
As for the C derived languages: C is one of the most beautiful languages out there. It succeeds at everything it tries to be - a portable, friendly looking variant of assembler. I can't really say the same about C++, but criticism of C++ is best left for another day.
