Certainly not the worst in this list, but it was annoying anyway.
We had an huge NMR and MRI room on the place where I did my traineeship.
Of course we were warned (already at the uni) that NMR has a tendency to corrupt electronic devices, and even can be dangerous if it attracts keys through your pants, but that is usually not as bad as stated. However one of these baby did eat stuff.
The expensive machinery (several millions each, had 3) was shared with a different institution and heavily used, so we made it a habit to come in an hour late, and stay an hour longer to use the NMR stuff after normal hours. Of course we were in a rush to go home, and you sometimes forget to empty all of your pockets.
Watches, any card with a magnetic strip, PDA's, totally wiped out or dead. One trainee left keys in his pocket, and he lost the pocket of his levi's when changing a probe on the machine.
We all bought "Seiko Automatics" (these are the older, fully mechanical eq of Seiko Kinetics) watches because they were mechanical, but while it seemed to work at first, after a while they were dead also. Probably the magnetic field twisted the delicate mechanical parts after a while. While Kinetics lasted the longest, they were also significantly more expensive, so we were back at roaming the fair grounds for cheap watches:_)
"Mussel glues present the first identified case in which transition metals are essential to the formation of a non crystalline biological material," says NSF CAREER awardee Jonathan Wilker of Purdue University.
I'm no NSF CAREER awardee, but a mere Chemical Engineering drop out, but I can name hemoglobine, which is not crystaline (commonly used in solution), _needs_ iron, and is quite useful for life
I'm in the compiler,languages and tools business, and I've heard a few myself.
- speed doesn't matter with todays computers. (one shouldn't be overfocussed on speed, but totally neglecting it is also wrong) - garbage collection doesn't affect speed. (it does, and also mem-footprint. If it is a problem depends on the app) - scripting languages are in speed near to compiled languages (C, C++, Delphi were named in this discussion), or even faster due to runtime optimizing
I also have that feeling. (porting the best back to FreeBSD).
It seems that there is one production BSD, FreeBSD, and the other ones are research projects, the best of which will be snatched later by the production free Unices FreeBSD and Linux
- NetBSD : portability, cleanness - OpenBSD: Security, also a bit portability and cleanness, and a huge batch of stubbornness. - DragonFly: Mach kernel experiments. - Darwin: Also Mach kernel experiments.
It's not that the above OSes don't have a merit for the user. They got the features in their own terrain first, and due to the fact that they are generally smaller and cleaner can copy eachother faster.
If you happen to really need the feats under research, that can be important.
However the forks can simply not live up to FreeBSD and Linux (and then specially/i386)'s driver base, release engineering, large scale package management and advanced enterprise features.
(too quick)... Lazarus (lazarus.freepascal.org) is working hard on it, but while it is quite nice for a lot of purposes, and indeed does a lot of the GUI grunt work fast, easy and efficient, it is still not a 100% dropin replacement for Delphi.
YMMV a lot depending on the kind of applications you have though. I can certainly recommend to test it.
I don't think so. I don't see anything comparable to Kylix in the Linux C market.
Except maybe Borlands own C++ builder, but that came much later, and much too late to actually have anything to do with Kylix problems. (and Kylix problems probably extend to the Linux version of C++ builder too)
I can hardly name one open source RAD, in the same style as VB and Kylix, let alone something that is competitive. (RAD is IMHO integrated IDE+UI design.)
Lazarus (lazarus.freepascal.org) is working hard on it.
Re:it's pretty obvious...
on
Kylix in Limbo
·
· Score: 1
I followed a (borland site) link from some Delphi-Jedi maillist IIRC. Can't reproduce it, but it was on the Borland site IIRC.
-- Yes, but if I have to rewrite the code to a cut off language, which is pretty close to C# with slightly different syntax and some small portability extensions, I might as well start from scratch in C#. (either by porting the existing Delphi to C# instead of delphi.net or clean from scratch).
The fine differences between (object) Pascal and C(++), that go deeper than {} vs begin..end are then lost, the backwards Delphi compability is already gone, and I'm not that big a zealot that that doesn't seriously reraises the question why I'm shopping at Borland.
Luckily I don't have to decide now, but if I have to fork the code like this into
- Delphi32 (Delphi/win32 but also FPC for Linux,FreeBSD and maybe Mac in the near future),
- and something.NET
I might as well cut the Borland bond, and start over for C# (using the D32 sources as start).
-- But I'm in the lucky place that all my customers, though not necessarily negative about.NET, think that.NET is a bit hyped, and that early adopting will increase costs, and deliver no advantages.
I beg to differ. VB is actually more popular than C/C++.
Re:it's pretty obvious...
on
Kylix in Limbo
·
· Score: 1
Actually they put the win32 development in the fridge, but octane will be win32 capable.
The problem with "writing.NET in the language of your choice" is that I'll have to "rewrite near all of the code I have in the language of my choice" to make it work, since managed code requires a lot of changes.
(libs, language constructs, win32 api calling all differ)
Re:it's pretty obvious...
on
Kylix in Limbo
·
· Score: 1
Or if you have to make a program that is non trivial of course.
Or a GUI program with hundreds of dialogues.
Strictness is only useful when teaching, and when programs get *big*
Re:it's pretty obvious...
on
Kylix in Limbo
·
· Score: 1
Because that is also a lot of work, and a lot less control.
And no, that only makes sure that the most basic level of the cg is somewhat portable, you still have to implement everything on top of it.
And that is even diminished we already yank tables from NASM and gcc to construct the lowest level.
It's like in the real world. A new wheel is cheaper than reusing the old wheel.
Moreover the FPC codegenerator is geared to generating code for Pascal, including all quirks, directly, without detours.
There is also no need to negotiate with the gcc team for changes to the backend, gcc version management, costly migrations to a new major gcc version etc.
The amount of needed buildtools is smaller (as,ld,make only, no bison, collect, etc)
Re:it's pretty obvious...
on
Kylix in Limbo
·
· Score: 2, Informative
This is partially true, but Lazarus is only usable for just under a year.
I also don't pretend that lazarus is a drop in replacement.
However it does allow to recompile most non-visual Delphi sources with the brandnew 1.9 Free Pascal compiler. (that is much closer to D6 compat then the old one), and it is actual GUI design a la Delphi, not distro or even OS dependant (which does it for me, Debian and FreeBSD here)
FPC moreover is tinkering with PPC, Sparc and Arm, and there is serious hope this will be up and running with lazarus in late spring next year
Re:Not the right product for Linux
on
Kylix in Limbo
·
· Score: 1
I think this is nonsense. Delphi never worked on NT4/alpha and NT4/sparc, and that never stopped it from getting marketshare.
The non x86 crowd using Linux is very small. (and yes, I'm one of them), and there is simply no interest.
The rest is as portable as Kylix apparantly, since nothing comparable from another vendor will work on my linuxppc machine.
The problem is the VCL being copyrighted, and windows specific (which is worse then a bit assembler), but more important the zero size of the non x86 linux market, and the fact that the linux market isn't appararntly mature enough for this kind of productivity tools. A lot of companies checking out linux, a lot of departments tinkering, but not enough professional application development to sustain such a beast, even without any comparable competition.
Kylix had a lot of downsides compared to Delphi, but so did D1. The _I'm alone in this market_ factor should have easily made up for that.
It is a bitter truth I know, but I think it should be said
Re:it's pretty obvious...
on
Kylix in Limbo
·
· Score: 2, Informative
>Who needs Kylix when you can write your GUIs in >Python using wxWindows, GTK, or QT for FREE?
_productivity_
>Who needs Kylix when you can write your GUIs in >Perl using wxWindows, GTK, or QT for FREE?
_productivity_
>Who needs Kylix when you can write your GUIs in >C/C++ using wxWindows, GTK, or QT for FREE?
_productivity_
In other words the exact same reasons why the bulk of the professional programmers on Windows doesn't use this.
Kylix was not targeted at the hobbyist programmer, _OR_ the serious programmer with a difficult task.
It was targeted at - converting delphi source. (e.g. database clients) to create a corporate Delphi software market. - Productivity while building new (GUI) linux apps.
For the hobbyist, or professional that is at home at unix, Kylix was less useful, because of the sheer size, the distro requirements etc.
And of course you have
Who needs Kylix when you can _drag and drop_ your GUIs in Delphi's Pascal using Lazarus (lazarus.freepascal.org) FOR FREE ?:-)
As a bonus, it works on FreeBSD and (soon) linux/ too
Re:I own a copy
on
Kylix in Limbo
·
· Score: 0, Redundant
Try Free Pascal (aka FPC www.freepascal.org)
with Lazarus (lazarus.freepascal.org) as IDE.
It's a real find.
Re:Not free - not interested
on
Kylix in Limbo
·
· Score: 1
The bulk of those tools, and more is available in some form on Windows too.
Still VS6 and VS.NET rule the scene (with Borland also taking a small part of the pie).
- VB is not C either, and Basic was more regarded
as a toy. - Turbo/Borland Pascal, Delphi predecessor was as
standard as Delphi, and that never held it back
from dominating a quite large part of the dos
market - There is some truth in that. (the Microsoft part) though.
I think Borland simply can't compete on price with Microsoft. Microsoft writes of its toolchain development on the OS sales.
Microsoft floods the markets with cheap development tools (e.g. full versions of VS studio at MCSE meetings)
Slashdot Mirror
(actually, wheel)
/usr as mortal user using your favourite package system?
Btw, you can install packages into
Brr....
I'd like that too:_)
I forgot the fun of explaining your bank that your ATM card didn't work anymore about once every three weeks
Certainly not the worst in this list, but it was annoying anyway.
We had an huge NMR and MRI room on the place where I did my traineeship.
Of course we were warned (already at the uni) that NMR has a tendency to corrupt electronic devices, and even can be dangerous if it attracts keys through your pants, but that is usually not as bad as stated. However one of these baby did eat stuff.
The expensive machinery (several millions each, had 3) was shared with a different institution and heavily used, so we made it a habit to come in an hour late, and stay an hour longer to use the NMR stuff after normal hours. Of course we were in a rush to go home, and you sometimes forget to empty all of your pockets.
Watches, any card with a magnetic strip, PDA's, totally wiped out or dead. One trainee left keys
in his pocket, and he lost the pocket of his levi's when changing a probe on the machine.
We all bought "Seiko Automatics" (these are the older, fully mechanical eq of Seiko Kinetics) watches because they were mechanical, but while it seemed to work at first, after a while they were dead also. Probably the magnetic field twisted the delicate mechanical parts after a while. While Kinetics lasted the longest, they were also significantly more expensive, so we were back at roaming the fair grounds for cheap watches
better than the avg linuxer.
That most grand projects "rewrite X from scratch" never reach the 1.0 level, or that they cost years beyond the original estimate?
One could do a lot of small bugfixing in that time
"Mussel glues present the first identified case in which transition metals are essential to the formation of a non crystalline biological material," says NSF CAREER awardee Jonathan Wilker of Purdue University.
I'm no NSF CAREER awardee, but a mere Chemical Engineering drop out, but I can name hemoglobine, which is not crystaline (commonly used in solution), _needs_ iron, and is quite useful for life
man objdump
I'm in the compiler,languages and tools business, and I've heard a few myself.
- speed doesn't matter with todays computers. (one shouldn't be overfocussed on speed, but totally neglecting it is also wrong)
- garbage collection doesn't affect speed. (it does, and also mem-footprint. If it is a problem depends on the app)
- scripting languages are in speed near to compiled languages (C, C++, Delphi were named in this discussion), or even faster due to runtime optimizing
I also have that feeling. (porting the best back to FreeBSD).
/i386)'s driver base, release engineering, large scale package management and advanced enterprise features.
It seems that there is one production BSD, FreeBSD, and the other ones are research projects, the best of which will be snatched later by the production free Unices FreeBSD and Linux
- NetBSD : portability, cleanness
- OpenBSD: Security, also a bit portability and cleanness, and a huge batch of stubbornness.
- DragonFly: Mach kernel experiments.
- Darwin: Also Mach kernel experiments.
It's not that the above OSes don't have a merit for the user. They got the features in their own terrain first, and due to the fact that they are generally smaller and cleaner can copy eachother faster.
If you happen to really need the feats under research, that can be important.
However the forks can simply not live up to FreeBSD and Linux (and then specially
That's what I don't get. Why the calculation of the Strouhal number doesn't involve size.
Since size (and friction coefficient, which is related to streamlining) matters for e.g. friction, and friction effects efficiency.
Maybe the difference is negiable since all birds are usually quite streamlined, and gas friction is much less than friction in fluid.
I looked at the Strouhal numbers link, and what
immediately struck me is that there is no correction for bird size.
The wingspan (amplitude) is in the equation, but not for this (it is used as a factor to determine the thrust)
I'd expect the friction factor and a measure for the size of the bird (e.g. surface that is seen from the front) in there.
(too quick) ... Lazarus (lazarus.freepascal.org) is working hard on it, but while it is quite nice for a lot of purposes, and indeed does a lot of the GUI grunt work fast, easy and efficient, it is still not a 100% dropin replacement for Delphi.
YMMV a lot depending on the kind of applications you have though. I can certainly recommend to test it.
I don't think so. I don't see anything comparable to Kylix in the Linux C market.
Except maybe Borlands own C++ builder, but that came much later, and much too late to actually have anything to do with Kylix problems. (and Kylix problems probably extend to the Linux version of C++ builder too)
I can hardly name one open source RAD, in the same style as VB and Kylix, let alone something that is competitive. (RAD is IMHO integrated IDE+UI design.)
Lazarus (lazarus.freepascal.org) is working hard on it.
I followed a (borland site) link from some Delphi-Jedi maillist IIRC. Can't reproduce it, but it was on the Borland site IIRC.
--
Yes, but if I have to rewrite the code to a cut off language, which is pretty close to C# with slightly different syntax and some small portability extensions, I might as well start from scratch in C#. (either by porting the existing Delphi to C# instead of delphi.net or clean from
scratch).
The fine differences between (object) Pascal and C(++), that go deeper than {} vs begin..end are then lost, the backwards Delphi compability is already gone, and I'm not that big a zealot that that doesn't seriously reraises the question why I'm shopping at Borland.
Luckily I don't have to decide now, but if I have to fork the code like this into
- Delphi32 (Delphi/win32 but also FPC for Linux,FreeBSD and maybe Mac in the near future),
- and something
I might as well cut the Borland bond, and start over for C# (using the D32 sources as start).
--
But I'm in the lucky place that all my customers, though not necessarily negative about
So I have the time to wait luckily
I beg to differ. VB is actually more popular than C/C++.
Actually they put the win32 development in the fridge, but octane will be win32 capable.
.NET in the language of your choice" is that I'll have to "rewrite near all of the code I have in the language of my choice" to make it work, since managed code requires a lot of changes.
The problem with "writing
(libs, language constructs, win32 api calling all differ)
Or if you have to make a program that is non trivial
of course.
Or a GUI program with hundreds of dialogues.
Strictness is only useful when teaching, and when programs get *big*
Because that is also a lot of work, and a lot less control.
And no, that only makes sure that the most basic level of the cg is somewhat portable, you still have to implement everything on top of it.
And that is even diminished we already yank tables from NASM and gcc to construct the lowest level.
It's like in the real world. A new wheel is cheaper than reusing the old wheel.
Moreover the FPC codegenerator is geared to generating code for Pascal, including all quirks,
directly, without detours.
There is also no need to negotiate with the gcc team for changes to the backend, gcc version management, costly migrations to a new major gcc version etc.
The amount of needed buildtools is smaller (as,ld,make only, no bison, collect, etc)
This is partially true, but Lazarus is only usable for just under a year.
I also don't pretend that lazarus is a drop in replacement.
However it does allow to recompile most non-visual Delphi sources with the brandnew 1.9 Free Pascal compiler. (that is much closer to D6 compat then the old one), and it is actual GUI design a la Delphi, not distro or even OS dependant (which does it for me, Debian and FreeBSD here)
FPC moreover is tinkering with PPC, Sparc and Arm, and there is serious hope this will be up and running with lazarus in late spring next year
I think this is nonsense. Delphi never worked on NT4/alpha and NT4/sparc, and that never stopped it from getting marketshare.
The non x86 crowd using Linux is very small. (and yes, I'm one of them), and there is simply no interest.
The rest is as portable as Kylix apparantly, since nothing comparable from another vendor will work on my linuxppc machine.
The problem is the VCL being copyrighted, and windows specific (which is worse then a bit assembler), but more important the zero size of the non x86 linux market, and the fact that the linux market isn't appararntly mature enough for
this kind of productivity tools. A lot of companies checking out linux, a lot of departments tinkering, but not enough professional application development to sustain such a beast, even without
any comparable competition.
Kylix had a lot of downsides compared to Delphi, but so did D1. The _I'm alone in this market_ factor should have easily made up for that.
It is a bitter truth I know, but I think it should be said
>Who needs Kylix when you can write your GUIs in >Python using wxWindows, GTK, or QT for FREE?
_productivity_
>Who needs Kylix when you can write your GUIs in >Perl using wxWindows, GTK, or QT for FREE?
_productivity_
>Who needs Kylix when you can write your GUIs in >C/C++ using wxWindows, GTK, or QT for FREE?
_productivity_
In other words the exact same reasons why the bulk of the professional programmers on Windows doesn't use this.
Kylix was not targeted at the hobbyist programmer, _OR_ the serious programmer with a difficult task.
It was targeted at
- converting delphi source. (e.g. database clients) to create a corporate Delphi software market.
- Productivity while building new (GUI) linux apps.
For the hobbyist, or professional that is at home at unix, Kylix was less useful, because of the sheer size, the distro requirements etc.
And of course you have
Who needs Kylix when you can _drag and drop_ your GUIs in Delphi's Pascal using Lazarus (lazarus.freepascal.org) FOR FREE ?
As a bonus, it works on FreeBSD and (soon) linux/ too
Try Free Pascal (aka FPC www.freepascal.org)
with Lazarus (lazarus.freepascal.org) as IDE.
It's a real find.
The bulk of those tools, and more is available in some form on Windows too.
Still VS6 and VS.NET rule the scene (with Borland also taking a small part of the pie).
Productivity is the difference.
This is nonsense, since:
- VB is not C either, and Basic was more regarded
as a toy.
- Turbo/Borland Pascal, Delphi predecessor was as
standard as Delphi, and that never held it back
from dominating a quite large part of the dos
market
- There is some truth in that. (the Microsoft part) though.
I think Borland simply can't compete on price with Microsoft. Microsoft writes of its toolchain development on the OS sales.
Microsoft floods the markets with cheap development tools (e.g. full versions of VS studio
at MCSE meetings)