I think the parent is absolutely correct, seaside has been doing this for years with halos, code browsers, inspectors, search browsers, etc. You can also easily build your own because of how Smalltalk works (the dev UI uses Smalltalk and it is fully meta-driven by the language itself).
Maybe I am missing something, but I am not sure what you are talking about regarding seaside refreshing. If you had bothered to download, install, use seaside, or even read the documentation, you would know that seaside almost never does a full page refresh.
The whole point of the seaside framework is that it is stateful like a desktop application. There is no need to refresh the page. If you look carefully or take a peek at the code, it refreshes just the UI component you are working with, for example a code browser or halo.
You can change the actual URL via your components to create the illusion of switching pages, or even do a redirect, but the design used is to swap components in the UI as needed, not refresh the page. The page can maintain your state or even persist most parts of it long after your gone, so vs. almost every other popular web framework, there is next to no risk of losing your work unless you coded it as such. I don't think you understand seaside and how it uses sessions in conjunction with state management, script, and the web context.
FYI, seaside does use a lot of these "DHTML technologies." It also uses a ton of AJAX if you want, and does indeed support the back button (old seaside versions used backtracing for instance) quite well (better than almost any other AJAX framework, plus you can customize this behavior easily).
The one thing you are even close to being correct about is this technology has been around for nearly a decade. Actually, longer. Seaside is a continuations based web framework, and others have been around to some degree for awhile. Seaside took its inspiration from web objects for example.
The real scape goat here is superman. If only superman would stop putting all those missiles in the way, we would not have this problem. And don't get me started about all those chunks of his tacky colored planet. Always blaming general zod, some sort of cosmic event, or something and never taking real responsibility. Don't litter.
Anyway, I think it's time we ask him to clean his room so to speak. If he can't do it, I guess plan b is some sort of friggin gundam laser.
Microsoft has CLR code running on top of MS SQL but it sucks performance wise. Oracle has Java. That's about as close as we have gotten, but both are just crutches.
Unfortunately, you are right that SQL is terrible and not going away. The status quo, industry, and marketing will make sure we suffer for years to come.
You are misunderstanding me, but perhaps I was not clear. Architecture with the right hardware makes a difference of course. My point was it was no longer technically impractical to run certain types of databases. Certainly every database loves more hardware.
There are plenty of tuple and graph stores that support distributed transactions. There are also plenty that have not been updated, but just as many in the relational world. It is in the nature of graph and tuple stores to scale out in this way. Most of the major implementations already do this quite well and much more elegantly than any replication based solution in the relational world.
I am not sure what you are getting at here other than straying a bit off topic from what I was commenting about. Regardless, yes, I agree with you.
I agree with you on a lot of points, particularly people coming up with stupid solutions and creating new problems, but how is the rest of this insightful? Sure, relational is a good general fit databases, but it sounds like you are saying the fact that you can query and modify it using something like SQL in most implementations makes it great?
Exactly how is that easier than some other ways, such as building an object database? Can't you just write a few lines of code that are far more expressive than any SQL ever could be in a language like Common Lisp, Smalltalk, Python, Ruby, etc? Isn't that more accomodating than a relational model which limits your options due to performance vs. flexibility vs. integrity vs. extensibility vs. scalability? How does SQL give you more ways to manipulate things than a map, collect, slice, reduce, anonymous function/lambda, etc?
I use both relational and object databases (preference to object dbs in all honesty). For an object database, my process both in use and development is to write and modify like it sounds, objects. Instances of objects in those classes are automatically stored for me and even in most implementations, class level data as well. I simply write my code and trudge along and do not worry about some ridiculous ORM. If I need transactions, I have them at the object level which I would want anyway even with a relational DB.
If I need a query, it is done in a well-known language that I used to write the application. I can of course see if there was no application, it might annoying to do this and relational can make some of that easier, but that is rarely the case. Further, I don't hit as many bumps where I need to denormalize my data to do reporting or data warehousing. I simply once again write code as normal to get what I want.
A great example is try storing an organizational hierarchy in a database. Query it for basic info such as a list of a manager and all subordinates and superiors. Now try to ask it for the full path between employees. Keep asking it questions about the hierarchy. In just about every relational db it is a fail. Oracle for instance even realized things like this and added "Connect By." Storing the data itself is a nightmare and you end up needing something like nested sets, self joining queries, cursors (never), handing it off to an application (aka relational failure), or materialized path.
You run into other similar problems where you see hackish solutions in the realtional world like table inheritance. Why have it if a relational database is so good? It is there because relational completely fails here, just like object databases fail elsewhere. There is no ideal solution, and for general cases both work great in my experience, even giving an edge for web applications to object dbs.
There are so many areas where either the relational model itself, or SQL fails. If you have not hit them, then you have not used relational databases as much more than a glorified spreadsheet. The amount of time I spend tuning my queries in a relational db is ridiculous, even for relatively simple data. Hints, denormalization, columns as rows, cursors, triggers, user defined functions, and other such devices are all crutches for relational dbs. Of course some of those are also caused by bad devs of course, but it need not be that hard in the first place.
Anyway, I am not trying to slam the relational model. Rather, I think you are wrong to say it's the best and most flexible. Like all things, it depends what you are doing, and in my own experience object databases have been far easier to work with and maintain. I must save months of work every time I use one, but general ignorance often forces me to use either object or relational. If people better understood the strengths of each and paid more attention to each specific task rather than marketing, we would all be happier. It's sad that complaints about tools for example are even valid points. If you market the hell out of something and it just becomes the standard for whatever reason, then of course it is going to win in areas like that. You would think with all the anti-Microsoft rhetoric around here, people would get it.
For now, I'll continue to use both and enjoy them for different reasons.
It seems like every time I read one of these articles, it is written by someone with no knowledge of what is actually out there. I suppose that is normally because anyone with enough time to mouth off on the internet in article or blog form is not actually doing real work. The rest of us are too busy, you know, working?
Anyway, as someone that has been programming, particularly against just about every major database platform out there, I can tell you that there has always been a battle between relational vs. other types of databases, most notably graph databases. Full disclosure: I am partial to graph databases, but that is because I find a lot of utility in working in pure code and I also apply graph theory to a lot of my work.
There is no silver bullet and each kind of database is better at certain tasks. Long ago, hardware made much more of a difference than it does today and was one reason relational databases "won" out. Other reasons include marketing, the development of SQL and other standards, and the ease of applying relational mathematics which are easy to understand. I spent most of my life working with relational databases as they were simply in my comfort zone, until I realized I needed to get off my ass and learn more than just new languages and programming techniques (and realized relational dbs were such a huge fail at tasks like traversing graphs, storing dynamic columns ala a CRM, etc).
Particularly when you look at older languages like LISP, relational was a great fit vs. graph. Since then, many factors have caught up and many more languages, solutions, and designs are out there. In the meantime, graph databases never went away. It seems suddenly since the outbreak of "web 2.0" frameworks and ORMs, a lot of people who don't have a clue about SQL, and especially databases in general of all types find it a great idea to go out and make their own or put some huge hack on top of a relational db, or perhaps worse, try to come up with something entirely new that is not based on fact or need.
I've played around with some of the databases mentioned above, and just like MySQL, they are mainly reinventing the wheel badly. The google implementation is the only one I have seen that is not completely shoddy, but color me somewhat unimpressed as well. FYI, just because xyz company such as google or IBM uses some product does not make it good. On the contrary, it's often a warning sign as big companies are often what keeps sites like thedailywtf going.
Regarding graph databases, I'm currently using Gemstone with Smalltalk for instance, and I have used it with Java as well. I can tell you it is great, but it is no panacea. It's been around forever like many of its competitors which are also noteworthy, but a side-by-side comparison is best left outside the scope of this comment. Gemstone lets me avoid any ORM overhead and I can write and maintain queries, transactions, reports, etc in one place; my code where they belong for my projects. It's fast as hell and I have collections with millions of objects and there is no slow down. In fact, I migrated many of my databases from other systems including Oracle, DB2, MS SQL, and Postgres, and it smokes them all, but I am confident that if I can think of a huge laundry list of tasks where the opposite will be true.
For instance, I can do reporting using Gemstone as I mentioned, but it is left up to me writing my own code or using a library, where in something like MS SQL, I can just use reporting services to do more complicated cubes, or one of the 100 enterprise reporting tools of various size for Oracle. It also sucks in some ways if you need to share a lot of data between applications because you have to make decisions about what do you want to split out and how to manage the memory and load.
Even Gemstone itself is not so bold as to presume there is no use for relational databases. You can build a SQL layer on top of it and it has many tools to move data back and forth between any relational db, for instance.
Java was a good idea, but there are lots of other languages that came before that had all the characteristics you describe. I would argue that most of those already did a better job than Java but were marketed or supported poorly at various stages.
I use.NET every day as well as Java and I agree MS did a better job. MSIL is a great concept, but unfortunately too much of the framework has deep hooks in windows to work in whole cross platform. Mono of course tries to solve this issue, but I wish MS would be a little more careful about how much they bake windows into everything.
I think the answer is to use the best language for the job and that means Java is long from being irrelevant given the wealth of functionality available to us today.
"well, TBH, there's Smalltalk too, but who, these days, is building anything substantial in Smalltalk?)"
Perhaps http://www.seaside.st/ ? Financial industry? If anything, Smalltalk is picking up a lot more momentum and popularity recently. It's a great alternative if you're sick of Java or C# or don't buy into Rails hype.
That said, I agree with everything else you said. I too work with Java (and C#) quite often and I have to say that Java has so many open source libraries and support it's amazing and makes up for many of the things I hate.
I agree this is dead so I won't go on too much more, but one thing I would ask is why does it matter to use SVN and such? I know this is certainly a reality when you're in an existing environment, but for a Smalltalk "shop" or even one that is ok leaving its Smalltalk developers/code alone, it's a non-issue. Smalltalk has several "built-in" source control repositories which work just fine (See Squeak Smalltalk for instance).
I also like the fact that in an image, I can Snapshot the entire thing. That doesn't just include my code, but my settings, environment, and even runtime. It makes sharing and deploying things a snap, but I can see how some may dislike that.
You mention wanting to use grep. I feel like that is a giant wtf for the way I do things. True, when I write in file languages I admit to it, but I don't see it as the right way. For one, searcihng files is not really aware of how my code works. If I want that functionality, I need to write even more complex additions to my searching programs. Contrast that with the Smalltalk implementations you mentioned. In Squeak for example, I can bring up dozens of different search browsers that can do everything from scope my search to a class name to a method even. The search is fully aware of Smalltalk and how it works, to the point where it can even be used for refactoring quite easily in addition to the other refactoring tools. I would never go back to grep if I didn't have to in other languages.
As for changes to to the core classes, other than an update which is rare, I don't see existing methods ever changing. The only way they change is some stupid developer which sucks, but that's life when it's all open. The method count is fine with me since it's well designed and consistent. Smalltalk's browsers make sure everything is organized so it feels like less code and for me, mentally I can conceptualize the code when it's put into specific categories (closest thing in java is regions, but you're still looking at a giant file). I don't do well with a large amount of vertical text in my face. That doesn't and almost can't happen in Smalltalk.
Actually longer. An "object database" is really just a graph database. Objects refer to eachother via pointer chains, and it forms a graph. There's really no extra semantic value there, object databases are just graph databases adapted to OO development styles.
This is what I was implying of course.
Relational database systems were invented to overcome the semantic problems with graph databases, not the performance problems.
True, but that is not the only reason. It's a long discussion and I mentioned there are many limitations.
Here you start a list of very condescending remarks about relational database systems. Have you considered the possibility that many people use relational database systems because they are informed and implementing a new application; not in spite of those facts?
I didn't I say it depends on the situation? Just because someone knows about object databases doesn't mean they are stil making the right choice. In fact, I would say it's the norm that people have the knowledge but don't properly apply it when it comes to IT projects.
More of the same. Object databases aren't newer or better, they are repackaged graph databases. Businesses are "hanging on" to RDBMSs because they are the best thing out there (although you may be able to criticize some specific implementation).
I think you should really consider whether you're looking for a DBMS at all. If all you want is persistence, you should consider solutions along those lines.
It doesn't sound like you have used any quality ojbect databases. You're also pointing out the obvious, even more so given I actually did mention graph databases. You're also behaving like what I was hinting at; that there is this culture of resistance. I will use any technology that works and is proven. I don't feel any loyalty to any company or technology. Show it to me and I will learn and use it if it is quality.
I use both relational and object databases, again, depending on the task. My point was people equate database with RDBMS, and what the reasons for that are, along with some of the implications of switching. Show me some concrete data that prove RDMBS are the "best" thing out there as you claim. I guarantee in many situations both in terms of productivity for developers and database performance that RDBMS get smoked. The reverse is true in some cases as well. Ultimately, people need to look at their problem domain and decide which is a better fit. You'd be shocked how many web applications are a great fit for an object DB.
You're chiding me for given an honest opinion rather than trying to make nice, but you're doing the same thing in your reply. There's no denying things like ORMs and the mess the relational world has created. The industry has spent so much effort on skirting around these problems while there are existing implementations that are free from these problems because it's again a matter of applying technology correctly. Sure, there are plenty of situations where we want relational and ORMs and such, but arguments can be made there also on the application side.
Amen. All students should study the MySQL source to learn what not to do when designing a database. It's only fitting it is the database of choice for PHP. Together, they form voltron, or is it Mr. Hankey?
I must give them credit, they have improved the database by many orders of magnitudes between versions. My mom said learn from your mistakes. I guess they took it a little too seriously at the start.
Not trying to start a war here, but seriously Databases != RDBMS. It seems like no one knows that object databases have been around a long time too. In the context of the article, many of the points can be applied to all types of databases, but it's so focused on the RDBMS (no shock considering the author).
There were a multitude of issues in the past with object databases from agendas, performance, complexity, etc that put relational databases at the forefront. Hardware and the quality of object databases has more than caught up, so why are object databases so rarely used still?
One answer why object databases are ignored to a large degree is that people don't like to stray from the norm and tend to implement what they know. Another possibility is many people simply have never even heard of the concept of object databases. Further, in academia we almost exclusively focus on relational databases in most courses. Finally, legacy data is perhaps the biggest hurdle.
A corollary to the issues above is that there is an entire industry of DBAs and developers that fight learning something new. There's also mega corps with billions invested in the concept of the relational databases. I don't blame MySQL and some of the things said in the article because they're just trying to improve, but on the user level, it's amazing how much effort goes into adapting the RDBMS into the online world and resulting crazy architecture/technologies/code.
Object relational mappers are a great example of our unwillingness to leave the RDBMS world(unless you're working with legacy/existing data of course, but even then, investigate the possibility to migrate). Why do we need ORMs in the first place? They are a product of using relational databases. When I'm programming, I want to work in objects and not bizarre mapping layers, complicated DALs, etc. We spend so much time on mapping and layers to build bridges between a relational and object world at the cost of productivity and performance simply to continue to hang on to our old RDBMSs.
I've found that in most cases, object databases are faster for my projects. I've also tried related databases like grid/network databases. There are definitely cases where relational databases are also better, but I would use one over the other on a case-by-case basis. I find for the average case I've seen, hardware and architecture tips the balance in favor of object databases because of the way how we want to model things using objects anyway. If we look at a popular type of app right now, a social network... why use a relational database? Typically the associations and structures we make are objects and hierarchies or networks. Relational databases are ill suited at both. Instead, we start to develop hack and wtf schemas, rely to heavily on the app to sort out the data, or introduce object database-like concepts like table inheritance. This also forces us to introduce and learn yet another language.
SQL is a huge discussion in itself. I find SQL brilliant and easy to use, but nonetheless ill-suited for many tasks. Once cursors, user defined functions, etc. were introduced, the nightmare got worse. I find procedural and object constructs instead of set based constructs in SQL created by clients all the time as a result. This ends up crippling performance and instead of fixing the issues, decision makers will just throw more hardware at the problem or ignore it all together. There's also this myth that somehow SQL creates a way for the layman to query data in the database. This is true to a small degree, but has mutated into something not unlike "human readable" for XML.
I'm certified in SQL Server and Oracle, and Postgres is my home RDBMS of choice, so certainly I have a lot invested, but if I'm offered something that is better I will gladly abandon all my intellectual and time investments in these systems. I use whatever works the best for the task. After building several apps using Gemstone over the years, I have to cringe every time I return to Oracle or even w
Always interesting to hear from the radicals that go on about what's "true abstraction" and "true polymorphism" and programmers that "resist real change" yet use a language that has *zero* encapsulation. And yes I am talking about smalltalk.
The "Integer/int thing" means Java is acceptable for numerical work whereas Smalltalk is not. I don't see how you can call me or anyone else a radical unless you lack understanding of these subjects. First, I use Java and C# for most of my daily work at present. I think you confuse static typing and the necessary evils it creates with encapsulation. Perhaps you are using that as a crutch to justify encapsulations, to which Java inhibits and adds significant complexity in many cases. This has caused huge WTFs to the point where I now see people circumventing static typing and compilation by using reflection to do things like having a true factory class without writing 10000 lines of extra code, at which point your whole "encapsulation" goes out the window anyway according to your logic.
Second, no one ever alleged to use Smalltalk for numerical work. It's fine for most numerical work on modern hardware anyway. That said, yes in some cases I would use other languages including Java, C++, and Fortran.
What's your point here? Have we not been discussing to some degree the right tool for the job? How often are you doing such severe number crunching that your language is getting in the way anyway? I find that's the more "radical" point of view. I'd rather have productivity and optimize performance later than rely on the language to do it for me 100%.
The same things you probably like about Java make it much less productive and unsuitable for the web vs. a multitude of other languages as the current trend reveals including: Smalltalk, Python, Ruby, and even PHP. There's no reason why you can't use multiple languages anyway, which is exactly what I do to begin with.
Interesting. I think it's obvious we disagree but I can see your point of view. Again, I think of course it's a personal perference as some of the things you want/mention I loathe. Perhaps we approach development differently. Can you list for me what you specifically don't think we should do in a language that Smalltalk does? I'm always curious to have other opinions and to be shown languages that make up for failures in others.
You mentioned Java. Java in general I think is how not to design a language. If I had to pick a language closer to Java, it would definitely be C# over Java simply because I feel like C# is Java done right (but still wrong), Microsoft lock-in aside.
I am still not sure how you can say Smalltalk is more complex than Java. I don't think number of methods or even number of keywords map directly to complexity; rather I believe complexity is something you don't discover until writing real-world projects. I don't see Java's 11 methods on type object as being an advantage at all. Smalltalk chooses to implement its underlying machinery in itself. This results in more methods of course, though in Smalltalk most of these we wouldn't even call methods at all (another topic). Java does the same to a degree, but I feel Smalltalk's approach is a lot cleaner. It's not uncommon in Smalltalk to have lots of methods, but if you actually go and look at the underlying implementation, rarely will you see a method more than five lines. Java on the other hand has methods that span hundreds of lines in some cases. I don't allege that means one is more complex than the other either, however I think it highlights that the general coding approach as a product of the language differs greatly in Smalltalk. Ultimately, it's apples and oranges.
You also mentioned Javascript. Like everyone, I've used Javascript extensively and I can't stand in, even with some of the nice "advanced" features with prototyping and such. Javascript is a hard language to talk about given that many of the obvious reasons to hate it one can blame on VM implementations, browsers, and people's ignorance.
I think the reason that Javascript is "successful" is that it is baked into web browsers as the defacto scripting language of choice. That would make nearly any language "successful." Few people I've ever met concede that the actual implementation is one that they like. I think most of us would prefer just about any other language aside from vbscript baked into the browser.
I have to believe that even if you separate Javascript from the browser, get rid of the inept procedural developers trying to use it, and consequently shift the blame of some of those flaws on to the browser's handling of DOM, memory, etc, instead, Javascript would still be a wtf.
Overall, I am curious how you think Smalltalk fails on an implementation level? Smalltalk has never made me feel like I couldn't do something easily or the language inhibited me. I think the language is easy to learn and forces you to develop well given the dev environment is integrated into the language/implementation philosophy.
What about the image do you not like? I think dropping the image defeats some of the design of Smalltalk, and that's one reason why something like Smallscript couldn't succeed because it seems weird to many Smalltalk developers and weird to people who didn't like Smalltalk anyway. I find people who are scared off by the image concept don't understand how Smalltalk works. I've often seen people who don't know Smalltalk post about how they wish they could write code in Eclipse, emacs, or notepad. That makes no sense if you think about the impact of the image. Without the image, intellisense wouldn't work/would suck, refactoring built-in capabilities would be limited, you would loose or have to rebuild all the types of browsers, the debugging would be much harder, etc. It's a weird concept for some to accept that the image and the language are in many ways one entity. What do you feel like files gain you? I don't see the use case wh
Frankly, "Smalltalk is successful" is nothing more than a sham. You yourself listed 12+ 'language killer' problems with Smalltalk, agree that basically nobody ever used it and that it is old and outdated... but you still call it a 'success'? !/boggl You obviously have a decent background and I agree with some of the tings you said, but overall I'm going to have to question what you wrote.
No, I was saying Smalltalk is successful to me for some of the reasons I listed. I said it was not successful in terms of industry and popular terms. I don't think the 12+ language killers you are referring to are problems. Personally, those are likely the reasons I love the language.
Fileless language? Brilliant IMO and forces people to be organized in a structured way. VM? Great idea, makes deployment a snap, restore the state of your dev environment, etc. Need I remind you how VMs in general are all the rage now? Lack of extensive keywords? Makes it simple to learn and extend because the language is essentially written in itself, no weird dropping to C or other languages (see Ruby) causing all kinds of issues. Outdated? It's updated more or less daily and even has several new web frameworks (just not 2.0 buzzword oriented like Ruby on Rails sorry, etc.). Frankly, I find Smalltalk to be way ahead of the curve as far as keeping up with the rest of the pack in most areas because there are some great coders that share their stuff and churn it out quick, and the rest was already implemented in the past few decades anyway. How many times can we reinvent a datetime library? Lots of major changes != good language.
If you think no one ever used it, then you really lack an understanding of the language and its history. It's certainly more of a niche language than PHP, but it's not exactly an experimental research language either. I think you might be equating your own personal exposures to general usage.
In general, your first sentence sums it up. Smalltalk is successful because it implements both existing and new ideas well to the point where at least the ideas got more exposure, adoption, and notice. You can wrap all the features in a language you want, but the wrong blend makes it taste terrible. Smalltalk did quite a nice job and that's the reason people give it credit and other languages follow suit. Did you ever stop and think maybe there is a reason people give it credit? Note that I never claimed it was original as you pointed out.
As an aside, my favorite language for code reasons is actually Lisp, but I find developing in Smalltalk is much easier because of the philosophy and design on the language. I find Lisp more powerful, but less clear and about equally expressive for most things. I'd choose Lisp if I was going purely on language design, and Smalltalk for actual implementation from code to deployment. For me, Lisp tastes great but has a bit of an unwanted after taste in some areas. It's a personal thing.
Anyway, again, for me both Smalltalk and Lisp are successful because they help me do great work vs. other languages. I don't consider most popular languages successful because I'd rather die than write code in them, but unfortunately it's hard to escape reality when you're selling your services in the open market. I don't see how you can call Smalltalk a Sham unless you're trying to troll. All languages are good in some way, but we all have our preferences.
Actually, quite a few. Ask the Gemstone Smalltalk and Visual Works guys. IBM did tons of Smalltalk awhile ago. In the financial world, it's quite popular and I've personally encountered lots of market related industries that rely on smalltalk for the important stuff. Often you'll see something like java or.net on the front end, but the important stuff behind the scenes is still smalltalk.
I've come across quite a number of wtfs of people who thought replacing a 15 year old smalltalk implementation with php or java was a great idea. It might well have been, but they failed to consider it's been running for 15+ years because it actually works as advertised. In the end, it's people too lazy to learn something new and investigate, but I can't blame that on a language either.
Finally, and not directly related to your post, I am still boggled by how people consider Java Object Oriented. It's Object Like for sure, but as long as you have to jump through so many hoops just to have true abstraction and polymorphism, and as long as classes have to advertise everything about their interfaces I personally think it's a steaming pile of crap. And that's to say nothing about the Integer/int thing.
I couldn't agree with you more on all points, especially on Java. It's great people can learn from and improve previous efforts, but sometimes I wish we could come up with something new. It's really hard considering how much programmers resist real change in their thought processes.
If so we can definitely add Fortran to that list. We can also add Basic and maybe even for a time, Pascal. Certainly all are wtf languages that I am glad are out of favor.
Simply put, the language is consistent and doesn't force any obvious wtfs, leaving the wtf creation in the hands of the developer. I look for the following:
-Does it accomplish its base characteristics without falling down? i.e. if it's object oriented, how easy is it to implement classical concepts? If it's functional, is it truly or just some lackluster hack of a language? etc. PHP is one language that fails miserably at being object oriented because it was really procedural before and despite changes, causes design wtfs because of the way the core libraries are implemented. C# is becoming another because it's throwing in language features from other sub-types of languages that don't belong even if they are nice to have, which brings me to my next point...
-Purity. It's really nice if the language sticks to what it does and doesn't try to be a swiss army knife. Often what happens in the square peg in round hole syndrome. It's common when trying to take a feature from a dynamically typed language into a statically typed language. All the sudden I can completely circumvent and break the type system if I want.
-Consistency. I want the core to be designed the same and not look like I just pulled in whatever I found on the street. Nothing is worse than unwanted side-effects and having to dig through mounds of docs because the language has no direction internally.
-Stability. Don't change the core libraries and functionalities all the time. Pick something, stick with it until you can do major releases. If the changes need to be so drastic, consider simply inventing a new language and enabling interoperability with old code through some kind of api, vm, or layer.
-Does it support standards? The major one I see a lot is almost no/buggy unicode/utf-8 support. In the world of globalization, there's no longer a support for this.
-Development environment. Is it easy to use? Are there tools? Intellisense is always a great one for productivity (no, it's not a crutch). Generally, I don't want to be fighting my environment to write code. Let me fight the code instead if I must have a battle.
-Configuration Management/Build Tools. If your language needs to be compiled, this is especially relevant. Code is worthless if you can't introduce configuration management practices to handle real-world situations like versioning. You could of course build your own CM/build tools, but it's nice to not have to do this. It's also nice is the language itself doesn't produce wtfs in this area. I'm looking at you C++ developers.
-Portable. This is low priority for me, but important depending on the job. Nice to know that you're not locked into an environment, OS, or hardware.
-Quality of core libraries. Honestly, do I really want to spend all my time writing string functions that don't suck? Considering that the general practice in code is to build upon and expand existing code by adding new code that uses your implementations, it's great if the default implementation isn't a joke.
-Still updated? Don't want abandonware.
-Performance. Depends on the task you need it for, but could determine if you use it or not. I wouldn't pick ruby or lua to write a 3d renderer.
-Can I hire people to implement it? I disagree with this point entirely because I don't want to work with people that are incapable of learning. I'd rather hire someone smart who doesn't know xyz language. Bias aside, some companies don't have the time luxury, but that's a wtf in itself. How many people have hired a Java "expert" only to find how badly the person sucks. Better imo to look for all around talent.
-Resources/Books? I don't care about this one but some do. It's nice to have, but if I have the source to the language, I can figure most things out pretty quick. Smalltalk is a nice one here because if you want to figure out the best way to do something, just look at the so called core libraries for good examples in many cases. In a similar sense, the material is grossly lacking and out of date compared to PHP.
I'm sure there are way more I can think of, but this is off the top of my head. I think it's a good start.
It's hard not to turn this discussion into a war and I do believe that even from a qualitative perspective, this discussion is entirely subjective. Let me preface my comments by saying I work primarily in C#, Java, Ruby, and Python in my job, and previously was a C, C++, Fortran, and Assembly programmer. I know about a dozen more languages as well, so I feel I've at least had exposure to many languages to guage success from a developer's point of view. Generally, I think being good at a certain job/task makes a language successful. There is a corollary that one should pick the best tool for the job, not because it's the "best" language. C++ is successful because it was very fast at the time, had a lot of features people wanted, and was relatively easy to learn. Would I do a web page in C++ these days? Probably not.
If I had to pick a language to discuss and deem successful, it would be either Smalltalk or Lisp. Some people find either of those esoteric or "weird," but I rather enjoy writing code in both. Interestingly enough, in many respects neither language is particular successful in a commercial sense, but very much so for most implementations.
I'll stick to Smalltalk because it's a good example for this discussion. It's a case where popularity in my mind is not equal to success. Smalltalk works because it is simple (there are really only 6 keywords or so and not even really keywords at that) and is designed impeccably. If success is related to imitation and admiration, then Smalltalk is up there. Of course in itself, the language is derivative, but it's well-known enough to claim/steal credit for one of the best implementations of existing ideas. I have to laugh at other languages, especially Ruby, Python, C#, and Java as they are adding language features or libraries that emulate things that have existed in Smalltalk for 20+ years. That's rather laughable, but also an indicator of success.
As the Smalltalk saying goes, "Files? How quaint." The language just proves you can design something successful by simplifying and focusing on enabling people to design and use their brains. I feel like I can focus on code rather than language constraints. Smalltalk coding is like teaching them to farm rather than giving them food. There are obvious merits to both approaches. The fact that the language is still around 20+ years later and gaining momentum speaks volumes.
I think what makes it unsuccessful is that a lot of people have no idea it exists in the first place and how it really works. They might look at it and say, "yeah that looks something like Ruby, so what's the point." Usually I find it's lack of understanding of not only Smalltalk, but the fact that the development environment in many ways is the language. Most Smalltalk implementations simply don't have the problems in file-based languages like disorganized code, "too many classes," etc. So many of the plights in other languages don't happen in Smalltalk because of the design and that to me is success, regardless of the number of commercial installations.
Another issues that has halted the language's success in commercial spaces has been ugly UI. Until recently, most implementations have looked awful. Squeak used to look like a child's toy without customizations (still does to some degree, but there's 100s of customized images floating around the internet now). Visual Works looks like an ugly ms-app sometimes, but is a huge leap over the past. Gemstone Smalltalk has no real UI (but can use Squeak). The list goes on, but the point is that even in dev environments, eye candy has a big influence.
It gets even weirder when you look at Smalltalk and languages from the perspective of supporting products. Databases are probably the biggest, and Smalltalk can work with just about everything, but the simple support for the RDBMS is pitiful compared to most popular languages. Especially in recent years, a lot of that has to do with the Smalltalk view. In the Smalltalk world, it seems stupid not to use an object database at this poin
Slashdot Mirror
I think the parent is absolutely correct, seaside has been doing this for years with halos, code browsers, inspectors, search browsers, etc. You can also easily build your own because of how Smalltalk works (the dev UI uses Smalltalk and it is fully meta-driven by the language itself).
Maybe I am missing something, but I am not sure what you are talking about regarding seaside refreshing. If you had bothered to download, install, use seaside, or even read the documentation, you would know that seaside almost never does a full page refresh.
The whole point of the seaside framework is that it is stateful like a desktop application. There is no need to refresh the page. If you look carefully or take a peek at the code, it refreshes just the UI component you are working with, for example a code browser or halo.
You can change the actual URL via your components to create the illusion of switching pages, or even do a redirect, but the design used is to swap components in the UI as needed, not refresh the page. The page can maintain your state or even persist most parts of it long after your gone, so vs. almost every other popular web framework, there is next to no risk of losing your work unless you coded it as such. I don't think you understand seaside and how it uses sessions in conjunction with state management, script, and the web context.
FYI, seaside does use a lot of these "DHTML technologies." It also uses a ton of AJAX if you want, and does indeed support the back button (old seaside versions used backtracing for instance) quite well (better than almost any other AJAX framework, plus you can customize this behavior easily).
The one thing you are even close to being correct about is this technology has been around for nearly a decade. Actually, longer. Seaside is a continuations based web framework, and others have been around to some degree for awhile. Seaside took its inspiration from web objects for example.
Hand over the genesis project Kirk, or your son dies.
The real scape goat here is superman. If only superman would stop putting all those missiles in the way, we would not have this problem. And don't get me started about all those chunks of his tacky colored planet. Always blaming general zod, some sort of cosmic event, or something and never taking real responsibility. Don't litter.
Anyway, I think it's time we ask him to clean his room so to speak. If he can't do it, I guess plan b is some sort of friggin gundam laser.
Microsoft has CLR code running on top of MS SQL but it sucks performance wise. Oracle has Java. That's about as close as we have gotten, but both are just crutches.
Unfortunately, you are right that SQL is terrible and not going away. The status quo, industry, and marketing will make sure we suffer for years to come.
You are misunderstanding me, but perhaps I was not clear. Architecture with the right hardware makes a difference of course. My point was it was no longer technically impractical to run certain types of databases. Certainly every database loves more hardware.
There are plenty of tuple and graph stores that support distributed transactions. There are also plenty that have not been updated, but just as many in the relational world. It is in the nature of graph and tuple stores to scale out in this way. Most of the major implementations already do this quite well and much more elegantly than any replication based solution in the relational world.
I am not sure what you are getting at here other than straying a bit off topic from what I was commenting about. Regardless, yes, I agree with you.
I agree with you on a lot of points, particularly people coming up with stupid solutions and creating new problems, but how is the rest of this insightful? Sure, relational is a good general fit databases, but it sounds like you are saying the fact that you can query and modify it using something like SQL in most implementations makes it great?
Exactly how is that easier than some other ways, such as building an object database? Can't you just write a few lines of code that are far more expressive than any SQL ever could be in a language like Common Lisp, Smalltalk, Python, Ruby, etc? Isn't that more accomodating than a relational model which limits your options due to performance vs. flexibility vs. integrity vs. extensibility vs. scalability? How does SQL give you more ways to manipulate things than a map, collect, slice, reduce, anonymous function/lambda, etc?
I use both relational and object databases (preference to object dbs in all honesty). For an object database, my process both in use and development is to write and modify like it sounds, objects. Instances of objects in those classes are automatically stored for me and even in most implementations, class level data as well. I simply write my code and trudge along and do not worry about some ridiculous ORM. If I need transactions, I have them at the object level which I would want anyway even with a relational DB.
If I need a query, it is done in a well-known language that I used to write the application. I can of course see if there was no application, it might annoying to do this and relational can make some of that easier, but that is rarely the case. Further, I don't hit as many bumps where I need to denormalize my data to do reporting or data warehousing. I simply once again write code as normal to get what I want.
A great example is try storing an organizational hierarchy in a database. Query it for basic info such as a list of a manager and all subordinates and superiors. Now try to ask it for the full path between employees. Keep asking it questions about the hierarchy. In just about every relational db it is a fail. Oracle for instance even realized things like this and added "Connect By." Storing the data itself is a nightmare and you end up needing something like nested sets, self joining queries, cursors (never), handing it off to an application (aka relational failure), or materialized path.
You run into other similar problems where you see hackish solutions in the realtional world like table inheritance. Why have it if a relational database is so good? It is there because relational completely fails here, just like object databases fail elsewhere. There is no ideal solution, and for general cases both work great in my experience, even giving an edge for web applications to object dbs.
There are so many areas where either the relational model itself, or SQL fails. If you have not hit them, then you have not used relational databases as much more than a glorified spreadsheet. The amount of time I spend tuning my queries in a relational db is ridiculous, even for relatively simple data. Hints, denormalization, columns as rows, cursors, triggers, user defined functions, and other such devices are all crutches for relational dbs. Of course some of those are also caused by bad devs of course, but it need not be that hard in the first place.
Anyway, I am not trying to slam the relational model. Rather, I think you are wrong to say it's the best and most flexible. Like all things, it depends what you are doing, and in my own experience object databases have been far easier to work with and maintain. I must save months of work every time I use one, but general ignorance often forces me to use either object or relational. If people better understood the strengths of each and paid more attention to each specific task rather than marketing, we would all be happier. It's sad that complaints about tools for example are even valid points. If you market the hell out of something and it just becomes the standard for whatever reason, then of course it is going to win in areas like that. You would think with all the anti-Microsoft rhetoric around here, people would get it.
For now, I'll continue to use both and enjoy them for different reasons.
It seems like every time I read one of these articles, it is written by someone with no knowledge of what is actually out there. I suppose that is normally because anyone with enough time to mouth off on the internet in article or blog form is not actually doing real work. The rest of us are too busy, you know, working?
Anyway, as someone that has been programming, particularly against just about every major database platform out there, I can tell you that there has always been a battle between relational vs. other types of databases, most notably graph databases. Full disclosure: I am partial to graph databases, but that is because I find a lot of utility in working in pure code and I also apply graph theory to a lot of my work.
There is no silver bullet and each kind of database is better at certain tasks. Long ago, hardware made much more of a difference than it does today and was one reason relational databases "won" out. Other reasons include marketing, the development of SQL and other standards, and the ease of applying relational mathematics which are easy to understand. I spent most of my life working with relational databases as they were simply in my comfort zone, until I realized I needed to get off my ass and learn more than just new languages and programming techniques (and realized relational dbs were such a huge fail at tasks like traversing graphs, storing dynamic columns ala a CRM, etc).
Particularly when you look at older languages like LISP, relational was a great fit vs. graph. Since then, many factors have caught up and many more languages, solutions, and designs are out there. In the meantime, graph databases never went away. It seems suddenly since the outbreak of "web 2.0" frameworks and ORMs, a lot of people who don't have a clue about SQL, and especially databases in general of all types find it a great idea to go out and make their own or put some huge hack on top of a relational db, or perhaps worse, try to come up with something entirely new that is not based on fact or need.
I've played around with some of the databases mentioned above, and just like MySQL, they are mainly reinventing the wheel badly. The google implementation is the only one I have seen that is not completely shoddy, but color me somewhat unimpressed as well. FYI, just because xyz company such as google or IBM uses some product does not make it good. On the contrary, it's often a warning sign as big companies are often what keeps sites like thedailywtf going.
Regarding graph databases, I'm currently using Gemstone with Smalltalk for instance, and I have used it with Java as well. I can tell you it is great, but it is no panacea. It's been around forever like many of its competitors which are also noteworthy, but a side-by-side comparison is best left outside the scope of this comment. Gemstone lets me avoid any ORM overhead and I can write and maintain queries, transactions, reports, etc in one place; my code where they belong for my projects. It's fast as hell and I have collections with millions of objects and there is no slow down. In fact, I migrated many of my databases from other systems including Oracle, DB2, MS SQL, and Postgres, and it smokes them all, but I am confident that if I can think of a huge laundry list of tasks where the opposite will be true.
For instance, I can do reporting using Gemstone as I mentioned, but it is left up to me writing my own code or using a library, where in something like MS SQL, I can just use reporting services to do more complicated cubes, or one of the 100 enterprise reporting tools of various size for Oracle. It also sucks in some ways if you need to share a lot of data between applications because you have to make decisions about what do you want to split out and how to manage the memory and load.
Even Gemstone itself is not so bold as to presume there is no use for relational databases. You can build a SQL layer on top of it and it has many tools to move data back and forth between any relational db, for instance.
The authors
Java was a good idea, but there are lots of other languages that came before that had all the characteristics you describe. I would argue that most of those already did a better job than Java but were marketed or supported poorly at various stages.
I use .NET every day as well as Java and I agree MS did a better job. MSIL is a great concept, but unfortunately too much of the framework has deep hooks in windows to work in whole cross platform. Mono of course tries to solve this issue, but I wish MS would be a little more careful about how much they bake windows into everything.
I think the answer is to use the best language for the job and that means Java is long from being irrelevant given the wealth of functionality available to us today.
"well, TBH, there's Smalltalk too, but who, these days, is building anything substantial in Smalltalk?)"
Perhaps http://www.seaside.st/ ? Financial industry? If anything, Smalltalk is picking up a lot more momentum and popularity recently. It's a great alternative if you're sick of Java or C# or don't buy into Rails hype. That said, I agree with everything else you said. I too work with Java (and C#) quite often and I have to say that Java has so many open source libraries and support it's amazing and makes up for many of the things I hate.
I agree this is dead so I won't go on too much more, but one thing I would ask is why does it matter to use SVN and such? I know this is certainly a reality when you're in an existing environment, but for a Smalltalk "shop" or even one that is ok leaving its Smalltalk developers/code alone, it's a non-issue. Smalltalk has several "built-in" source control repositories which work just fine (See Squeak Smalltalk for instance).
I also like the fact that in an image, I can Snapshot the entire thing. That doesn't just include my code, but my settings, environment, and even runtime. It makes sharing and deploying things a snap, but I can see how some may dislike that.
You mention wanting to use grep. I feel like that is a giant wtf for the way I do things. True, when I write in file languages I admit to it, but I don't see it as the right way. For one, searcihng files is not really aware of how my code works. If I want that functionality, I need to write even more complex additions to my searching programs. Contrast that with the Smalltalk implementations you mentioned. In Squeak for example, I can bring up dozens of different search browsers that can do everything from scope my search to a class name to a method even. The search is fully aware of Smalltalk and how it works, to the point where it can even be used for refactoring quite easily in addition to the other refactoring tools. I would never go back to grep if I didn't have to in other languages.
As for changes to to the core classes, other than an update which is rare, I don't see existing methods ever changing. The only way they change is some stupid developer which sucks, but that's life when it's all open. The method count is fine with me since it's well designed and consistent. Smalltalk's browsers make sure everything is organized so it feels like less code and for me, mentally I can conceptualize the code when it's put into specific categories (closest thing in java is regions, but you're still looking at a giant file). I don't do well with a large amount of vertical text in my face. That doesn't and almost can't happen in Smalltalk.
Actually longer. An "object database" is really just a graph database. Objects refer to eachother via pointer chains, and it forms a graph. There's really no extra semantic value there, object databases are just graph databases adapted to OO development styles.
This is what I was implying of course.
Relational database systems were invented to overcome the semantic problems with graph databases, not the performance problems.
True, but that is not the only reason. It's a long discussion and I mentioned there are many limitations.
Here you start a list of very condescending remarks about relational database systems. Have you considered the possibility that many people use relational database systems because they are informed and implementing a new application; not in spite of those facts?
I didn't I say it depends on the situation? Just because someone knows about object databases doesn't mean they are stil making the right choice. In fact, I would say it's the norm that people have the knowledge but don't properly apply it when it comes to IT projects.
More of the same. Object databases aren't newer or better, they are repackaged graph databases. Businesses are "hanging on" to RDBMSs because they are the best thing out there (although you may be able to criticize some specific implementation).
I think you should really consider whether you're looking for a DBMS at all. If all you want is persistence, you should consider solutions along those lines.
It doesn't sound like you have used any quality ojbect databases. You're also pointing out the obvious, even more so given I actually did mention graph databases. You're also behaving like what I was hinting at; that there is this culture of resistance. I will use any technology that works and is proven. I don't feel any loyalty to any company or technology. Show it to me and I will learn and use it if it is quality.
I use both relational and object databases, again, depending on the task. My point was people equate database with RDBMS, and what the reasons for that are, along with some of the implications of switching. Show me some concrete data that prove RDMBS are the "best" thing out there as you claim. I guarantee in many situations both in terms of productivity for developers and database performance that RDBMS get smoked. The reverse is true in some cases as well. Ultimately, people need to look at their problem domain and decide which is a better fit. You'd be shocked how many web applications are a great fit for an object DB.
You're chiding me for given an honest opinion rather than trying to make nice, but you're doing the same thing in your reply. There's no denying things like ORMs and the mess the relational world has created. The industry has spent so much effort on skirting around these problems while there are existing implementations that are free from these problems because it's again a matter of applying technology correctly. Sure, there are plenty of situations where we want relational and ORMs and such, but arguments can be made there also on the application side.
Amen. All students should study the MySQL source to learn what not to do when designing a database. It's only fitting it is the database of choice for PHP. Together, they form voltron, or is it Mr. Hankey?
I must give them credit, they have improved the database by many orders of magnitudes between versions. My mom said learn from your mistakes. I guess they took it a little too seriously at the start.
Not trying to start a war here, but seriously Databases != RDBMS. It seems like no one knows that object databases have been around a long time too. In the context of the article, many of the points can be applied to all types of databases, but it's so focused on the RDBMS (no shock considering the author).
There were a multitude of issues in the past with object databases from agendas, performance, complexity, etc that put relational databases at the forefront. Hardware and the quality of object databases has more than caught up, so why are object databases so rarely used still?
One answer why object databases are ignored to a large degree is that people don't like to stray from the norm and tend to implement what they know. Another possibility is many people simply have never even heard of the concept of object databases. Further, in academia we almost exclusively focus on relational databases in most courses. Finally, legacy data is perhaps the biggest hurdle.
A corollary to the issues above is that there is an entire industry of DBAs and developers that fight learning something new. There's also mega corps with billions invested in the concept of the relational databases. I don't blame MySQL and some of the things said in the article because they're just trying to improve, but on the user level, it's amazing how much effort goes into adapting the RDBMS into the online world and resulting crazy architecture/technologies/code.
Object relational mappers are a great example of our unwillingness to leave the RDBMS world(unless you're working with legacy/existing data of course, but even then, investigate the possibility to migrate). Why do we need ORMs in the first place? They are a product of using relational databases. When I'm programming, I want to work in objects and not bizarre mapping layers, complicated DALs, etc. We spend so much time on mapping and layers to build bridges between a relational and object world at the cost of productivity and performance simply to continue to hang on to our old RDBMSs.
I've found that in most cases, object databases are faster for my projects. I've also tried related databases like grid/network databases. There are definitely cases where relational databases are also better, but I would use one over the other on a case-by-case basis. I find for the average case I've seen, hardware and architecture tips the balance in favor of object databases because of the way how we want to model things using objects anyway. If we look at a popular type of app right now, a social network... why use a relational database? Typically the associations and structures we make are objects and hierarchies or networks. Relational databases are ill suited at both. Instead, we start to develop hack and wtf schemas, rely to heavily on the app to sort out the data, or introduce object database-like concepts like table inheritance. This also forces us to introduce and learn yet another language.
SQL is a huge discussion in itself. I find SQL brilliant and easy to use, but nonetheless ill-suited for many tasks. Once cursors, user defined functions, etc. were introduced, the nightmare got worse. I find procedural and object constructs instead of set based constructs in SQL created by clients all the time as a result. This ends up crippling performance and instead of fixing the issues, decision makers will just throw more hardware at the problem or ignore it all together. There's also this myth that somehow SQL creates a way for the layman to query data in the database. This is true to a small degree, but has mutated into something not unlike "human readable" for XML.
I'm certified in SQL Server and Oracle, and Postgres is my home RDBMS of choice, so certainly I have a lot invested, but if I'm offered something that is better I will gladly abandon all my intellectual and time investments in these systems. I use whatever works the best for the task. After building several apps using Gemstone over the years, I have to cringe every time I return to Oracle or even w
The "Integer/int thing" means Java is acceptable for numerical work whereas Smalltalk is not. I don't see how you can call me or anyone else a radical unless you lack understanding of these subjects. First, I use Java and C# for most of my daily work at present. I think you confuse static typing and the necessary evils it creates with encapsulation. Perhaps you are using that as a crutch to justify encapsulations, to which Java inhibits and adds significant complexity in many cases. This has caused huge WTFs to the point where I now see people circumventing static typing and compilation by using reflection to do things like having a true factory class without writing 10000 lines of extra code, at which point your whole "encapsulation" goes out the window anyway according to your logic.
Second, no one ever alleged to use Smalltalk for numerical work. It's fine for most numerical work on modern hardware anyway. That said, yes in some cases I would use other languages including Java, C++, and Fortran.
What's your point here? Have we not been discussing to some degree the right tool for the job? How often are you doing such severe number crunching that your language is getting in the way anyway? I find that's the more "radical" point of view. I'd rather have productivity and optimize performance later than rely on the language to do it for me 100%.
The same things you probably like about Java make it much less productive and unsuitable for the web vs. a multitude of other languages as the current trend reveals including: Smalltalk, Python, Ruby, and even PHP. There's no reason why you can't use multiple languages anyway, which is exactly what I do to begin with.
Interesting. I think it's obvious we disagree but I can see your point of view. Again, I think of course it's a personal perference as some of the things you want/mention I loathe. Perhaps we approach development differently. Can you list for me what you specifically don't think we should do in a language that Smalltalk does? I'm always curious to have other opinions and to be shown languages that make up for failures in others.
You mentioned Java. Java in general I think is how not to design a language. If I had to pick a language closer to Java, it would definitely be C# over Java simply because I feel like C# is Java done right (but still wrong), Microsoft lock-in aside.
I am still not sure how you can say Smalltalk is more complex than Java. I don't think number of methods or even number of keywords map directly to complexity; rather I believe complexity is something you don't discover until writing real-world projects. I don't see Java's 11 methods on type object as being an advantage at all. Smalltalk chooses to implement its underlying machinery in itself. This results in more methods of course, though in Smalltalk most of these we wouldn't even call methods at all (another topic). Java does the same to a degree, but I feel Smalltalk's approach is a lot cleaner. It's not uncommon in Smalltalk to have lots of methods, but if you actually go and look at the underlying implementation, rarely will you see a method more than five lines. Java on the other hand has methods that span hundreds of lines in some cases. I don't allege that means one is more complex than the other either, however I think it highlights that the general coding approach as a product of the language differs greatly in Smalltalk. Ultimately, it's apples and oranges.
You also mentioned Javascript. Like everyone, I've used Javascript extensively and I can't stand in, even with some of the nice "advanced" features with prototyping and such. Javascript is a hard language to talk about given that many of the obvious reasons to hate it one can blame on VM implementations, browsers, and people's ignorance.
I think the reason that Javascript is "successful" is that it is baked into web browsers as the defacto scripting language of choice. That would make nearly any language "successful." Few people I've ever met concede that the actual implementation is one that they like. I think most of us would prefer just about any other language aside from vbscript baked into the browser.
I have to believe that even if you separate Javascript from the browser, get rid of the inept procedural developers trying to use it, and consequently shift the blame of some of those flaws on to the browser's handling of DOM, memory, etc, instead, Javascript would still be a wtf.
Overall, I am curious how you think Smalltalk fails on an implementation level? Smalltalk has never made me feel like I couldn't do something easily or the language inhibited me. I think the language is easy to learn and forces you to develop well given the dev environment is integrated into the language/implementation philosophy.
What about the image do you not like? I think dropping the image defeats some of the design of Smalltalk, and that's one reason why something like Smallscript couldn't succeed because it seems weird to many Smalltalk developers and weird to people who didn't like Smalltalk anyway. I find people who are scared off by the image concept don't understand how Smalltalk works. I've often seen people who don't know Smalltalk post about how they wish they could write code in Eclipse, emacs, or notepad. That makes no sense if you think about the impact of the image. Without the image, intellisense wouldn't work/would suck, refactoring built-in capabilities would be limited, you would loose or have to rebuild all the types of browsers, the debugging would be much harder, etc. It's a weird concept for some to accept that the image and the language are in many ways one entity. What do you feel like files gain you? I don't see the use case wh
No, I was saying Smalltalk is successful to me for some of the reasons I listed. I said it was not successful in terms of industry and popular terms. I don't think the 12+ language killers you are referring to are problems. Personally, those are likely the reasons I love the language.
Fileless language? Brilliant IMO and forces people to be organized in a structured way. VM? Great idea, makes deployment a snap, restore the state of your dev environment, etc. Need I remind you how VMs in general are all the rage now? Lack of extensive keywords? Makes it simple to learn and extend because the language is essentially written in itself, no weird dropping to C or other languages (see Ruby) causing all kinds of issues.
Outdated? It's updated more or less daily and even has several new web frameworks (just not 2.0 buzzword oriented like Ruby on Rails sorry, etc.).
Frankly, I find Smalltalk to be way ahead of the curve as far as keeping up with the rest of the pack in most areas because there are some great coders that share their stuff and churn it out quick, and the rest was already implemented in the past few decades anyway. How many times can we reinvent a datetime library? Lots of major changes != good language.
If you think no one ever used it, then you really lack an understanding of the language and its history. It's certainly more of a niche language than PHP, but it's not exactly an experimental research language either. I think you might be equating your own personal exposures to general usage.
In general, your first sentence sums it up. Smalltalk is successful because it implements both existing and new ideas well to the point where at least the ideas got more exposure, adoption, and notice. You can wrap all the features in a language you want, but the wrong blend makes it taste terrible. Smalltalk did quite a nice job and that's the reason people give it credit and other languages follow suit. Did you ever stop and think maybe there is a reason people give it credit? Note that I never claimed it was original as you pointed out.
As an aside, my favorite language for code reasons is actually Lisp, but I find developing in Smalltalk is much easier because of the philosophy and design on the language. I find Lisp more powerful, but less clear and about equally expressive for most things. I'd choose Lisp if I was going purely on language design, and Smalltalk for actual implementation from code to deployment. For me, Lisp tastes great but has a bit of an unwanted after taste in some areas. It's a personal thing.
Anyway, again, for me both Smalltalk and Lisp are successful because they help me do great work vs. other languages. I don't consider most popular languages successful because I'd rather die than write code in them, but unfortunately it's hard to escape reality when you're selling your services in the open market. I don't see how you can call Smalltalk a Sham unless you're trying to troll. All languages are good in some way, but we all have our preferences.
Actually, quite a few. Ask the Gemstone Smalltalk and Visual Works guys. IBM did tons of Smalltalk awhile ago. In the financial world, it's quite popular and I've personally encountered lots of market related industries that rely on smalltalk for the important stuff. Often you'll see something like java or .net on the front end, but the important stuff behind the scenes is still smalltalk.
I've come across quite a number of wtfs of people who thought replacing a 15 year old smalltalk implementation with php or java was a great idea. It might well have been, but they failed to consider it's been running for 15+ years because it actually works as advertised. In the end, it's people too lazy to learn something new and investigate, but I can't blame that on a language either.
I couldn't agree with you more on all points, especially on Java. It's great people can learn from and improve previous efforts, but sometimes I wish we could come up with something new. It's really hard considering how much programmers resist real change in their thought processes.
Is popularity == success? Maybe.
If so we can definitely add Fortran to that list. We can also add Basic and maybe even for a time, Pascal. Certainly all are wtf languages that I am glad are out of favor.
Simply put, the language is consistent and doesn't force any obvious wtfs, leaving the wtf creation in the hands of the developer. I look for the following:
-Does it accomplish its base characteristics without falling down? i.e. if it's object oriented, how easy is it to implement classical concepts? If it's functional, is it truly or just some lackluster hack of a language? etc. PHP is one language that fails miserably at being object oriented because it was really procedural before and despite changes, causes design wtfs because of the way the core libraries are implemented. C# is becoming another because it's throwing in language features from other sub-types of languages that don't belong even if they are nice to have, which brings me to my next point...
-Purity. It's really nice if the language sticks to what it does and doesn't try to be a swiss army knife. Often what happens in the square peg in round hole syndrome. It's common when trying to take a feature from a dynamically typed language into a statically typed language. All the sudden I can completely circumvent and break the type system if I want.
-Consistency. I want the core to be designed the same and not look like I just pulled in whatever I found on the street. Nothing is worse than unwanted side-effects and having to dig through mounds of docs because the language has no direction internally.
-Stability. Don't change the core libraries and functionalities all the time. Pick something, stick with it until you can do major releases. If the changes need to be so drastic, consider simply inventing a new language and enabling interoperability with old code through some kind of api, vm, or layer.
-Does it support standards? The major one I see a lot is almost no/buggy unicode/utf-8 support. In the world of globalization, there's no longer a support for this.
-Development environment. Is it easy to use? Are there tools? Intellisense is always a great one for productivity (no, it's not a crutch). Generally, I don't want to be fighting my environment to write code. Let me fight the code instead if I must have a battle.
-Configuration Management/Build Tools. If your language needs to be compiled, this is especially relevant. Code is worthless if you can't introduce configuration management practices to handle real-world situations like versioning. You could of course build your own CM/build tools, but it's nice to not have to do this. It's also nice is the language itself doesn't produce wtfs in this area. I'm looking at you C++ developers.
-Portable. This is low priority for me, but important depending on the job. Nice to know that you're not locked into an environment, OS, or hardware.
-Quality of core libraries. Honestly, do I really want to spend all my time writing string functions that don't suck? Considering that the general practice in code is to build upon and expand existing code by adding new code that uses your implementations, it's great if the default implementation isn't a joke.
-Still updated? Don't want abandonware.
-Performance. Depends on the task you need it for, but could determine if you use it or not. I wouldn't pick ruby or lua to write a 3d renderer.
-Can I hire people to implement it? I disagree with this point entirely because I don't want to work with people that are incapable of learning. I'd rather hire someone smart who doesn't know xyz language. Bias aside, some companies don't have the time luxury, but that's a wtf in itself. How many people have hired a Java "expert" only to find how badly the person sucks. Better imo to look for all around talent.
-Resources/Books? I don't care about this one but some do. It's nice to have, but if I have the source to the language, I can figure most things out pretty quick. Smalltalk is a nice one here because if you want to figure out the best way to do something, just look at the so called core libraries for good examples in many cases. In a similar sense, the material is grossly lacking and out of date compared to PHP.
I'm sure there are way more I can think of, but this is off the top of my head. I think it's a good start.
It's hard not to turn this discussion into a war and I do believe that even from a qualitative perspective, this discussion is entirely subjective. Let me preface my comments by saying I work primarily in C#, Java, Ruby, and Python in my job, and previously was a C, C++, Fortran, and Assembly programmer. I know about a dozen more languages as well, so I feel I've at least had exposure to many languages to guage success from a developer's point of view. Generally, I think being good at a certain job/task makes a language successful. There is a corollary that one should pick the best tool for the job, not because it's the "best" language. C++ is successful because it was very fast at the time, had a lot of features people wanted, and was relatively easy to learn. Would I do a web page in C++ these days? Probably not.
If I had to pick a language to discuss and deem successful, it would be either Smalltalk or Lisp. Some people find either of those esoteric or "weird," but I rather enjoy writing code in both. Interestingly enough, in many respects neither language is particular successful in a commercial sense, but very much so for most implementations.
I'll stick to Smalltalk because it's a good example for this discussion. It's a case where popularity in my mind is not equal to success. Smalltalk works because it is simple (there are really only 6 keywords or so and not even really keywords at that) and is designed impeccably. If success is related to imitation and admiration, then Smalltalk is up there. Of course in itself, the language is derivative, but it's well-known enough to claim/steal credit for one of the best implementations of existing ideas. I have to laugh at other languages, especially Ruby, Python, C#, and Java as they are adding language features or libraries that emulate things that have existed in Smalltalk for 20+ years. That's rather laughable, but also an indicator of success.
As the Smalltalk saying goes, "Files? How quaint." The language just proves you can design something successful by simplifying and focusing on enabling people to design and use their brains. I feel like I can focus on code rather than language constraints. Smalltalk coding is like teaching them to farm rather than giving them food. There are obvious merits to both approaches. The fact that the language is still around 20+ years later and gaining momentum speaks volumes.
I think what makes it unsuccessful is that a lot of people have no idea it exists in the first place and how it really works. They might look at it and say, "yeah that looks something like Ruby, so what's the point." Usually I find it's lack of understanding of not only Smalltalk, but the fact that the development environment in many ways is the language. Most Smalltalk implementations simply don't have the problems in file-based languages like disorganized code, "too many classes," etc. So many of the plights in other languages don't happen in Smalltalk because of the design and that to me is success, regardless of the number of commercial installations.
Another issues that has halted the language's success in commercial spaces has been ugly UI. Until recently, most implementations have looked awful. Squeak used to look like a child's toy without customizations (still does to some degree, but there's 100s of customized images floating around the internet now). Visual Works looks like an ugly ms-app sometimes, but is a huge leap over the past. Gemstone Smalltalk has no real UI (but can use Squeak). The list goes on, but the point is that even in dev environments, eye candy has a big influence.
It gets even weirder when you look at Smalltalk and languages from the perspective of supporting products. Databases are probably the biggest, and Smalltalk can work with just about everything, but the simple support for the RDBMS is pitiful compared to most popular languages. Especially in recent years, a lot of that has to do with the Smalltalk view. In the Smalltalk world, it seems stupid not to use an object database at this poin